A focus jump nobody asked for interrupts typing in progress

What it is

Someone is typing in a slot when a script or late content yanks focus elsewhere: async validation jumping to the first error, an ad, a chat message, a late autofocus. The word being composed lands in the wrong slot, or a stump stays in the old one. Unsolicited focus steal is an interruption during input, not speak-order at page open, and not the legitimate handoff after the user opened a dialog.

Why it happens

Typing is a continuous motor plan; the insertion point is the nail that plan is hanging on. Move the nail between two keys and later characters land on the new nail; both slots’ contents are dirty. An IME composition buffer is more brittle: a steal before commit drops the syllable or types it into another app. The source is often “helpful”: validation wants to walk people to an error, chat wants to announce a message, a single-page route wants to focus main content. For someone mid-sentence those are the same event—the caret misbehaved. The user’s own Tab, click, or menu open is not a steal; they moved the nail.

Studying it

Have people type a continuous passage while firing async errors, inserting a notice, and doing a partial route update. Record whether focus left, characters in the wrong slot, lost composition. Factors: whether the steal happens during compositionstart, whether it is configurable. Outcomes: misplaced character count, angry undo, abandonment. On touch, a keyboard that lowers and rises is also a steal and needs its own condition. Do not measure on idle slots—idle jumps are cheap and hide in-progress loss.

Where it stops holding

Right after the user hits submit, jumping to the first error is requested navigation, so long as it happens after submit and not while they are still editing another field. A session timeout that pulls focus to login is a real interruption, but security wins; keep the unsubmitted draft if possible. Collaborative carets and other people’s edits should not take local focus. Games and remote desktops have their own focus protocols; web rules do not copy over.

Applying it

• Do not call focus() while composition or typing is in progress; make error copy inline without stealing, and move focus only after submit.
• Chat, notices, and ads must not take an insertion point that is mid-edit.
• If a route update must set focus, skip the case where document.activeElement is already an input-class control.
• Verify by typing in a slot with an IME on, while validation, a notice, and a partial refresh fire. If the caret jumps or half a syllable vanishes, it is a steal. A jump to an error field after submit should happen.

Related

• Within the group: E2.22.1 Focusing on load interrupts a screen reader’s document order · E2.22.2 Autofocus fits a single, obvious primary field · E2.22.3 A dialog should take focus on open and return it on close
• Adjacent: E6.03 Inline validation · E2.16 Autocomplete dropdowns
• Search terms: unsolicited focus steal · focus stealing · composition interruption