Make one-finger vertical swipes on the workspace terminal scroll tmux (and other mouse-aware apps) the same way mouse-wheel scrolling does today.
Scope
In scope: browser-side change in the workspace/job terminal host (server-core/.../web/component/terminal/terminal.js), plus updating the scroll tip on WorkspaceTerminalPage.
Out of scope: tmux/container config, server PTY / WebSocket protocol changes. Existing SHELL_INPUT / mouse-protocol path already works for wheel; touch just never reaches it.
Why this location
terminal.js creates a stock xterm.js instance and forwards onData to the WebSocket. Wheel scrolling already works because xterm.js turns wheel events into mouse-protocol sequences when the app enables mouse reporting. The bundled xterm does listen for touch, but that path is for its own gesture handling, not for synthesizing wheel / mouse-wheel buttons for apps like tmux. OneDev should bridge that gap in our wrapper rather than forking xterm.
Approach
After xterm.open(...), attach touchstart / touchmove / touchend / touchcancel listeners on the terminal DOM element (non-passive where we need preventDefault).
On single-finger vertical pans:
accumulate deltaY from touch movement
emit synthetic WheelEvents (deltaMode: DOM_DELTA_PIXEL) on the xterm screen element so the existing mouse-tracking / alt-buffer wheel handlers run unchanged
use a small movement threshold so taps still focus / place the cursor
preventDefault only after a vertical scroll gesture is recognized, so we do not break tap-to-focus
Keep server code (TerminalPanel, WebSocket messages) unchanged; synthesized wheel input continues to flow as SHELL_INPUT via xterm's normal mouse encoding.
Update the tippy help text on the terminal page to mention touch swipe when mouse mode is active, and keep the existing Ctrl-b[ copy-mode hint as a fallback.
Edge cases / acceptance
Case
Expected
tmux with mouse on
Vertical swipe scrolls history / panes like the mouse wheel
vim / less (alt buffer, mouse on or wheel-as-keys)
Same behavior as wheel
Normal shell scrollback (no mouse mode)
Touch scrolls xterm scrollback if available; otherwise no regression vs today
Tap / long-press / text selection
Unaffected
Desktop mouse wheel
Unaffected
Test plan
Touch device or browser device emulation against a workspace terminal.
Verify tmux mouse scroll, plain shell, and that mouse wheel / keyboard still work.
Smoke-test job terminal pages that reuse TerminalPanel / terminal.js.
Follow-up (optional, not required for first cut)
Tune swipe sensitivity / inertia to feel closer to native terminals.
Consider contributing or aligning with upstream xterm.js touch→wheel behavior so a future xterm bump can replace the local bridge.
If this plan looks right, we can open an enhancement issue (or retarget this one) and implement it.
Goal
Make one-finger vertical swipes on the workspace terminal scroll tmux (and other mouse-aware apps) the same way mouse-wheel scrolling does today.
Scope
server-core/.../web/component/terminal/terminal.js), plus updating the scroll tip onWorkspaceTerminalPage.SHELL_INPUT/ mouse-protocol path already works for wheel; touch just never reaches it.Why this location
terminal.jscreates a stock xterm.js instance and forwardsonDatato the WebSocket. Wheel scrolling already works because xterm.js turnswheelevents into mouse-protocol sequences when the app enables mouse reporting. The bundled xterm does listen for touch, but that path is for its own gesture handling, not for synthesizingwheel/ mouse-wheel buttons for apps like tmux. OneDev should bridge that gap in our wrapper rather than forking xterm.Approach
xterm.open(...), attachtouchstart/touchmove/touchend/touchcancellisteners on the terminal DOM element (non-passive where we needpreventDefault).deltaYfrom touch movementWheelEvents (deltaMode: DOM_DELTA_PIXEL) on the xterm screen element so the existing mouse-tracking / alt-buffer wheel handlers run unchangedpreventDefaultonly after a vertical scroll gesture is recognized, so we do not break tap-to-focusTerminalPanel, WebSocket messages) unchanged; synthesized wheel input continues to flow asSHELL_INPUTvia xterm's normal mouse encoding.Ctrl-b[copy-mode hint as a fallback.Edge cases / acceptance
mouse onTest plan
TerminalPanel/terminal.js.Follow-up (optional, not required for first cut)
If this plan looks right, we can open an enhancement issue (or retarget this one) and implement it.