This is a limitation of the HTML terminal host, not of your container or tmux setup.

OneDev's workspace terminal is an xterm.js instance in the browser. Mouse wheel scrolling works because the browser fires wheel events, and xterm.js forwards those to the PTY as mouse-protocol sequences when tmux has mouse reporting enabled. Touch swipes produce touchstart / touchmove / touchend instead; they do not generate wheel events on the terminal surface, and OneDev does not convert those touch gestures into wheel/mouse-protocol input for tmux.

That is why a container that supports touch scrolling in a native terminal still fails here: the touch path never leaves the browser host. The help tip on the terminal page reflects the intended scroll method today: enter tmux copy mode with Ctrl-b then [, scroll with arrow keys or Page Up/Down, and press q to exit.

If touch scrolling is important for your workflow, that would need an enhancement in the browser terminal (for example translating touch pans into wheel/mouse events while tmux mouse mode is active).

Thank you for the explanation. Please create an implementation plan.

Implementation plan: touch scrolling in the workspace terminal

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

• 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

1. After xterm.open(...), attach touchstart / touchmove / touchend / touchcancel listeners on the terminal DOM element (non-passive where we need preventDefault).
2. 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
3. Gesture rules:
   • ignore multi-touch (pinch / two-finger)
   • ignore mostly-horizontal pans (leave page swipe / selection alone)
   • 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
4. Keep server code (TerminalPanel, WebSocket messages) unchanged; synthesized wheel input continues to flow as SHELL_INPUT via xterm's normal mouse encoding.
5. 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

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.