Skip to content

fix(mobile): route terminal taps without opening the keyboard - #186

Closed
Lint111 wants to merge 4 commits into
Ark0N:masterfrom
Lint111:agent/split-mobile-terminal-taps
Closed

fix(mobile): route terminal taps without opening the keyboard#186
Lint111 wants to merge 4 commits into
Ark0N:masterfrom
Lint111:agent/split-mobile-terminal-taps

Conversation

@Lint111

Copy link
Copy Markdown
Contributor

Summary

Make terminal touches behave predictably on mobile without opening the software keyboard for TUI-owned content.

This PR is the focused tap/gesture slice extracted from the larger mobile-experience branch. It is intentionally limited to terminal-ui.js and its unit/browser regressions.

Behavior

  • Treat the first tap that opens the keyboard as focus-only, so it cannot also activate the currently highlighted CLI option.
  • Distinguish editable prompt rows from terminal content such as readbacks, tool results, permission choices, and status rows.
  • Forward content taps to Claude/Codex/Gemini as SGR mouse reports while keeping the keyboard closed.
  • Keep visible prompt taps focused on xterm's helper textarea.
  • Keep local scrollback taps inert while the user is reading history.
  • Recognize wrapped Claude Working / background-agent status rows as TUI content.
  • Forward touch drags to Claude's own transcript on verified Claude versions while retaining xterm-local scrolling for Codex and other modes.
  • Keep the live cursor and a small lower-screen input band focusable when a Claude redraw temporarily omits its prompt glyph.

Audit Fixes

The original classifier relied too heavily on visible prompt glyphs. During promptless Claude redraws, a live row could be classified as content, touchstart would suppress browser focus, and the mobile keyboard became unreachable.

The final commit gives precedence to known menus and working rows, then treats the live cursor and a four-row lower-screen fallback band as input. The browser regression verifies both required outcomes:

  • xterm's helper textarea becomes document.activeElement
  • no SGR mouse report is sent

The split also removes a hidden dependency on the separate history-anchor feature by using the existing local-scroll operations directly.

Commit Structure

  1. fix(mobile): keep keyboard focus taps non-activating
  2. fix(mobile): route terminal content taps to the CLI
  3. fix(mobile): route Claude terminal gestures
  4. fix(mobile): keep promptless terminal input focusable

Verification

  • npx vitest run --config config/vitest.config.ts test/terminal-touch-tap.test.ts
    • 25 passed
  • npx vitest run --config test/mobile/vitest.config.ts test/mobile/keyboard.test.ts -t "focuses the live Claude cursor|prevents Claude subagent status taps|focuses the terminal helper textarea when the visible prompt is tapped"
    • 3 passed, 32 skipped
  • Additional focused mobile browser checks:
    • readback collapse
    • prompt focus
    • local touch scroll
    • Claude transcript drag
  • npm run check:frontend-syntax
  • npm run check:public-assets
  • npx prettier --check test/mobile/keyboard.test.ts test/terminal-touch-tap.test.ts
  • npm run build

Non-Goals

  • Mobile virtual navigation controls and hardware volume-key fallback
  • Centralized IME, paste, draft, or delivery state
  • PTY viewport sizing ownership
  • Terminal history streaming, compression, caching, or frame reconciliation

@Lint111
Lint111 marked this pull request as ready for review August 2, 2026 05:43
CopilotAI review requested due to automatic review settings August 2, 2026 05:43

CopilotAI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR refines mobile terminal touch handling so taps and drags behave predictably without spuriously opening the software keyboard, while still forwarding TUI-owned interactions (mouse/touch gestures) to the underlying CLI when appropriate.

Changes:

  • Adds a mobile tap classifier to distinguish prompt/input rows from TUI content (readbacks, menus, Claude “Working/background” rows) and from local scrollback.
  • Routes content taps as SGR mouse reports while explicitly preventing keyboard focus; keeps prompt taps focus-only on the first tap to avoid accidental activation.
  • Extends mobile touch-drag scrolling to forward as SGR wheel events for verified Claude versions, while preserving local xterm scrolling for Codex/others; adds targeted unit + mobile regressions.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

FileDescription
src/web/public/terminal-ui.jsImplements tap classification + focus/blur routing; forwards selected touch scroll gestures as SGR wheel for verified Claude.
test/terminal-touch-tap.test.tsAdds unit coverage for tap classification, focus-only behavior, readback collapse, and touch scroll forwarding gates.
test/mobile/keyboard.test.tsAdds browser regressions ensuring content taps don’t focus the hidden textarea, prompt taps do, and Claude drags route to transcript scrolling.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

@Ark0N

Ark0N commented Aug 5, 2026

Copy link
Copy Markdown
Owner

Hi Lior, closing this one as part of a cleanup of the seventeen PRs currently open from you. The full explanation is in #173, and I would rather you read that one than this note, because it is the honest version and it is not a dismissal of your work.

The short form: sixteen PRs opened in a single day, roughly 42,000 added lines in total, landing mostly on the same few files (nine touch app.js, eight touch terminal-ui.js), with five already conflicting against master and none carrying CI results. I cannot review that at the standard this codebase needs, and merging it at a lower standard would be worse than not merging it.

Going forward, please keep no more than three open PRs at a time, each one a single behavior change that stands on its own, with a test that fails on master and passes with the fix. #214 and #215, merged today, are good models.

If this particular change fixes something that genuinely annoys you in daily use, it is a good candidate to be the first one you reopen on its own, rebased on current master. I will review it properly.

Thanks for the effort you put in, and sorry to close it this way.

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants

@Lint111@Ark0N