Repository navigation
Conversation
Claude Code, vim and less run on the alternate screen, usually with mouse reporting on. xterm.js drops its own touch handling while mouse events are active, and the alternate screen has no scrollback to move anyway - these apps scroll themselves when the terminal forwards the wheel. So a mouse wheel scrolled them and a finger did nothing. While the app owns scrolling (mouse tracking on, or the alternate buffer), a vertical drag is now turned into wheel events on the terminal, which xterm forwards exactly like a real wheel (SGR 64/65, or arrow keys without mouse reporting), with inertia after a flick. A plain shell on the normal buffer keeps xterm's own touch scrolling. Also undo CloudCLI's mobile 'user-select:text!important' on .xterm inside the plugin: on iOS it lets WebKit claim the drag as native text selection, after which touchmove never reaches the terminal at all.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
On touch devices a finger could not scroll full-screen apps — Claude Code, vim, less, htop — while a mouse wheel could. Two separate causes:
Mouse reporting / alternate screen. These apps run on the alternate screen, usually with mouse tracking on. xterm.js skips its own touch handling entirely while mouse events are active (
if (this.coreMouseService.areMouseEventsActive) return;in itstouchstart/touchmovelisteners), and the alternate buffer has no scrollback for a viewport scroll to move anyway. Such apps scroll themselves when the terminal forwards the wheel.New
src/touch.ts: while the app owns scrolling (terminal.modes.mouseTrackingMode !== 'none'or the alternate buffer is active), a vertical drag is turned intoWheelEvents on.xterm-screen. xterm then handles them exactly like a real wheel — SGR 64/65 with mouse reporting, arrow keys without it — and a flick keeps gliding briefly after the finger lifts. A plain shell on the normal buffer is left to xterm's own touch scrolling.Native text selection on iOS. CloudCLI's mobile stylesheet sets
.xterm, .xterm .xterm-viewport { user-select: text !important }(for the built-in Shell's tap-hold selection). That applies to the plugin's terminals too, and on iOS it lets WebKit claim a finger drag as native text selection — after whichtouchmovenever reaches the terminal at all. The plugin's stylesheet now restores xterm's ownuser-select: nonefor.wt-root .xterm.Testing
npm run typecheckandnpm run buildpass.ESC[<65;…/ESC[<64;…reports, with more arriving during the glide; a slow drag that parks before lifting does not glide;ESC[B/ESC[A;lessandvim, and in a plain shell's scrollback.npm test:resize reaches the PTYanda dropped connection keeps the shell alive…fail on unmodifiedmaintoo in my environment (Debian 13, Node 24). This change only touches the frontend.