fix(mobile): close the on-screen keyboard when tapping outside the terminal

[Lint111]

On a phone, once the on-screen keyboard is up there is no way to close it from inside the app.

The terminal keeps focus on a hidden textarea and nothing ever releases it, so tapping the header, the tab strip or any empty page chrome leaves the keyboard covering roughly half the screen. The only way out is the OS back gesture.

Repro

iPhone-class viewport (390×844), claude-mode session. Focus the terminal, then tap the header logo:

	document.activeElement after the tap
master	textarea.xterm-helper-textarea — keyboard stays up
this branch	body — keyboard closes

I found this on my own fork and checked it against pristine master before assuming it was mine: the behaviour is identical on both, so it is upstream, not something my branch introduced.

The change

A document-level touchend handler blurs the terminal input. It is deliberately narrow, because focus is not ours to take:

• only when the terminal input actually holds focus;
• never inside #terminalContainer — _handleMobileTerminalTap already classifies and routes those taps, and it owns that decision;
• never on a control. Anything focusable or clickable is about to take focus itself, and the keyboard accessory bar exists to be used while the keyboard is open, so dismissing there would fight the user. closest() covers taps that land on a child element, like an icon inside a button.

touchend rather than click: a tap meant to dismiss usually is not meant to activate whatever sits underneath, and touchend fires before the synthesized click, so the blur lands first. The listener is passive and never calls preventDefault.

Test

dismisses the on-screen keyboard when a tap lands outside the terminal, in test/mobile/keyboard.test.ts.

It fails on master with a behavioural assertion, not a TypeError:

AssertionError: expected 'xterm-helper-textarea' not to contain 'xterm-helper-textarea'

and passes here. It asserts all three cases in one gesture sequence — outside chrome dismisses, a visible button does not, inside the terminal does not — so it also guards against over-reach, not just the missing dismiss.

It drives real dispatched touch events rather than calling the helper directly. The handler is bound on document, so a direct call would bypass the routing the test exists to check. (That distinction cost me two wrong diagnoses on #244; it seemed worth encoding.)

Verification

Against master 26416f98:

npx tsc --noEmit clean
npm run check:frontend-syntax 32 files parse cleanly
npm run lint clean
npm run format:check clean
npm run test:ci 4944 passed | 12 skipped, 0 failed
test/mobile/keyboard.test.ts branch 5 failed | 47 passed (52)
test/mobile/keyboard.test.ts master 5 failed | 46 passed (51)

Identical five failures on both sides — stale layout and accessory-bar expectations plus a CJK timeout, all pre-existing and untouched here. The branch runs one more test and it passes: zero regressions.

Scope

2 files, +120. One behaviour change, no existing test weakened, and nothing outside the mobile keyboard path.

🤖 Generated with Claude Code

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[Lint111]

Pushed two follow-up commits after testing on a real device.

The dismiss handler fired on any touchend, and a scroll ends in touchend too. Scrolling to read something while composing closed the keyboard and dropped the composer — worse than the bug the PR fixes. My original test only ever dispatched a stationary tap, so it could not see this.

Fixed by tracking finger travel from touchstart and only treating a near-stationary gesture as a tap, using the same 8px TAP_THRESHOLD the terminal's own touch handling already uses so both agree on tap-vs-scroll. Multi-touch is never a dismissing tap. All three listeners stay passive.

Measured on a Pixel-class viewport with a Firefox UA:

gesture	result
tap	dismissed
scroll (120px)	keyboard kept
micro-drift (4px)	dismissed — an imprecise tap still works

The test now takes an optional travel distance and emits touchmove steps, and asserts the 120px scroll leaves the input focused. Removing the if (moved) return guard fails that assertion, so it pins the fix rather than just passing alongside it.

Re-verified: test:ci 4944 passed | 12 skipped, 0 failed; keyboard.test.ts 52 tests, same 5 pre-existing failures as master.