Merge pull request #268 from Ark0N/feat/mobile-shell-keyboard-262

feat(mobile): shell keyboard bar with a one-shot Ctrl modifier

src/web/public/terminal-ui.js

@@ -15,6 +15,15 @@
 (function (global) {
   const TERMINAL_QUERY_RESPONSE_PATTERN = /^\x1b\[[\?>=]?[\d;]*[cnR]$/;
   const TERMINAL_OSC_RESPONSE_PATTERN = /^\x1b\][\d;]*[^\x07\x1b]*(?:\x07|\x1b\\)$/;
+  // Pointer and focus reports xterm emits through onData on the terminal's OWN
+  // initiative, with no key pressed: SGR mouse (DECSET 1006, also 1016), legacy
+  // X10 mouse (DECSET 1000 — three raw bytes after CSI M) and focus in/out
+  // (DECSET 1004). They are not query REPLIES, so the query-response filter
+  // above does not match them, and they must keep reaching the PTY. What they
+  // must NOT do is stand in for a keystroke: see isTerminalFocusOrMouseReport.
+  const MOUSE_SGR_REPORT_PATTERN = /^\x1b\[<\d+;\d+;\d+[Mm]$/;
+  const MOUSE_X10_REPORT_PATTERN = /^\x1b\[M[\s\S]{3}$/;
+  const FOCUS_REPORT_PATTERN = /^\x1b\[[IO]$/;
   // Grace window after a manual scroll-up gesture during which sticky-scroll is
   // suppressed, so high-frequency Codex status redraws don't snap the viewport
   // back to the bottom while the user is inspecting earlier output.
@@ -106,6 +115,30 @@
     return isTerminalQueryResponse(data);
   }
 
+  /**
+   * Did the terminal generate this chunk itself, rather than a human pressing a
+   * key? True for mouse and focus reports (issue #262).
+   *
+   * Consumers that treat one onData chunk as "the next keystroke" must skip
+   * these. The one-shot Ctrl modifier is why this exists, and the MOUSE half is
+   * the live one: a shell session keeps the narrow scrollback strip, so mouse
+   * DECSETs reach the browser and anything the user runs that enables tracking
+   * (vim, htop, less) turns a tap into `\x1b[<0;31;23M`. Measured in a real
+   * shell session: with Ctrl armed, one tap on the terminal spent it silently.
+   *
+   * Focus reports are the same class and cost nothing to cover, but they cannot
+   * reach xterm today: `FOCUS_ESCAPE_FILTER` in session.ts strips `\x1b[?1004h`
+   * (and the reports themselves) from every PTY read, so `sendFocusMode` never
+   * turns on. Were that filter to go, the Ctrl button would spend the modifier
+   * on its OWN refocus — the bar refocuses the terminal after every key so the
+   * keyboard stays open, and that refocus emits `\x1b[I`.
+   */
+  function isTerminalFocusOrMouseReport(data) {
+    return (
+      FOCUS_REPORT_PATTERN.test(data) || MOUSE_SGR_REPORT_PATTERN.test(data) || MOUSE_X10_REPORT_PATTERN.test(data)
+    );
+  }
+
   // Per-skin xterm.js palettes. The 'daylight-blue' object equals the legacy hardcoded
   // theme, so default behavior is unchanged. Shared at module scope and exported on the
   // global so both terminal-ui.js (main terminal) and panels-ui.js (teammate terminals,
@@ -134,6 +167,7 @@
   global.CodemanTerminalInput = {
     isTerminalQueryResponse,
     shouldSuppressTerminalQueryResponse,
+    isTerminalFocusOrMouseReport,
     isComposerNavKey,
     classifyPredictInput,
     isCodexComposerRow,
@@ -930,6 +964,28 @@ Object.assign(CodemanApp.prototype, {
         ) {
           return;
         }
+
+        // ── One-shot Ctrl (mobile shell bar, issue #262) ──
+        // A virtual keyboard reports no usable key events, so a keydown hook
+        // would never see the character the modifier applies to: it arrives
+        // here as onData text. Sits AFTER the query-response filter so xterm's
+        // own DA/CPR replies can never spend the modifier, and BEFORE every
+        // send path so the control byte follows the normal control-char route
+        // (immediate flush, local-echo state cleared).
+        //
+        // Mouse and focus reports are skipped rather than suppressed: they are
+        // real bytes the PTY still needs, they just were not typed by anyone.
+        // A shell session passes mouse DECSETs through, so with vim or htop
+        // running, one tap on the terminal used to spend the modifier silently
+        // (measured against a real shell). See isTerminalFocusOrMouseReport.
+        if (
+          typeof KeyboardAccessoryBar !== 'undefined' &&
+          KeyboardAccessoryBar.isCtrlArmed?.() &&
+          !window.CodemanTerminalInput?.isTerminalFocusOrMouseReport(data)
+        ) {
+          data = KeyboardAccessoryBar.consumeCtrl(data);
+        }
+
         this._lastTerminalData = { data, time: performance.now() };
 
         // ── Local Echo Pass-through ──
@@ -2767,6 +2823,20 @@ Object.assign(CodemanApp.prototype, {
       _crashDiag.log(`CJK send DROP no-session len=${text.length}`);
       return;
     }
+    // ── One-shot Ctrl (mobile shell bar, issue #262) ──
+    // While the CJK field is visible it OWNS the keyboard: onData returns early
+    // for everything it swallows, and the focus router even redirects
+    // terminal.focus() into it — which is where the accessory bar sends focus
+    // after every key. So the onData hook never sees these keystrokes, and an
+    // armed modifier could neither fire NOR be spent: it survived until a
+    // session switch and then turned an innocent keystroke into a control byte.
+    // This is the module's single choke point to the PTY, so applying it here
+    // covers typed characters, IME flushes, Enter, backspace and arrows at once.
+    // Same policy as the onData hook: the next single character is modified,
+    // anything longer merely spends the modifier.
+    if (typeof KeyboardAccessoryBar !== 'undefined' && KeyboardAccessoryBar.isCtrlArmed?.()) {
+      text = KeyboardAccessoryBar.consumeCtrl(text);
+    }
     // Bypasses onData (like insertTerminalText): predictions cannot see this
     if (this._localEchoPolicy === 'predict') this._predictiveEcho?.clearPredictions();
     _crashDiag.log(`CJK send→${this.activeSessionId.slice(0, 8)} len=${text.length}`);