Repository navigation
fix(mobile): restore keyboard focus across tab switches and repeated dismissals - #37
Conversation
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the
 |
|
Repeated-dismiss candidate
Deployment readiness is NO while those runtime smoke checks fail. This follow-up has not been pushed or deployed; production remains on the previous frontend candidate. Native phone keyboard visibility remains unverified. Issue and draft PR remain open. Artifacts: |
johoja12
changed the title
|
Deployed the requested branch for phone testing at Fresh production-page probe: 12 simulated open/close cycles, 36 states, zero focus mismatches and zero offscreen helper inputs. Its disposable session was removed. This tests DOM focus and viewport handling, not native keyboard visibility. Actual phone confirmation is still needed; issue and PR stay open/draft. The broader smoke remains unresolved: correcting the temporary runner's reversed fallback wheel direction did not clear its long-scrollback return failure. Deployment is an explicitly requested candidate for phone testing, not a claim of green runtime gates. GitHub PR checks are pending. |
|
Fixed and deployed Completed validation:
Deployment readback: HTTP 200, codeman-web active; Local full sweep initially had one checkpoint build-suite failure from my concurrent builds deleting an asset during minification; 16,283 tests passed in that run. The checkpoint's isolated rerun passed all 10 tests, and the subsequent clean GitHub run passed the entire suite. This execution collision was not a product fix or a waived test. Native OS keyboard appearance is still unverified: Chromium touch emulation/viewport simulation cannot establish that result. Reload on the actual phone before checking repeated open/close. #35 remains open and #37 draft pending that confirmation. Evidence: |
|
Ran the requested live production touch-device emulation against Final run passed:
All temporary sessions/cases were removed. All 23 pre-existing sessions remain and their names/modes/directories/case links are unchanged. The test browser blocked terminal connections/activation for non-test IDs and did not forward shared preference or crash-diagnostic writes. Important limit: this is Chromium touch emulation with simulated viewport resizes, not native iPhone keyboard presentation. The no-resize control acquired DOM focus while keyboardDetected stayed false. Thus these passing web/app checks do not establish that the real phone's keyboard opens reliably; #35 remains open. Earlier attempts remain in the artifacts: startup notice blocked the first preflight; the floating Assistants launcher overlapped the first cursor point in another attempt (final test used an uncovered point on the same input row). A fast synthetic-typing/immediate-Enter attempt passed all 28 focus/input cycles but left a newline in Codex. The final run used 35ms per character and a 750ms pause before Enter, then submitted/responded successfully. No product patch or forced Enter retry was used to hide that result. Private local artifacts: |
|
Expanded live production touch test (v7 assets) completed November 1.
Outstanding finding: all 6 keyboard-open switch/reselect cases retained terminal DOM focus after simulated native dismissal. Diagnostics show the focus generation advanced during tab selection but the keyboard owner still referred to the previous generation, so onKeyboardHide skipped release. This is a concrete ownership mismatch relevant to the real iPhone report; Chromium still accepts subsequent touch focus/input, so it does not establish the native keyboard failure or its resolution. Harness correction: the initial run stopped at scenario 14 because a prompt tap happened while the mobile tab picker was still sliding closed. That attempt and screenshot are preserved. The completed rerun waits for the picker to physically clear the viewport before touching the terminal, independently of the injected terminal-load delay. No forced clicks or programmatic focus fallback were used. Artifacts (private local): /tmp/codeman-touch-tabs-prod-20261101/report.json, run.cjs, run.log, final.png; first attempt in attempt-1/. Test engine was Chromium with iPhone UA, mobile CSS, real touch events, and simulated viewport shrink/restore. Native iPhone keyboard appearance remains unverified. No application code change or deployment was made for this test; issue remains open and PR remains draft. |
|
Deployed follow-up fix 5905558 (v8 diagnostics, package version remains 1.47.0). RCA: tab/search selection advances the terminal focus generation while the existing keyboard remains visible. No new viewport shrink occurs to refresh dismissal ownership. Its next hide therefore skips release because the owner still refers to the old generation. Fix: after an explicit session-tab request survives the 350 ms focus-settle interval, transfer dismissal ownership to that request only if its target, generation and keyboard-open viewport geometry remain unchanged. This timer never focuses or blurs. Closing geometry, another editor, another request, hidden page or cleared keyboard ownership prevents adoption. Late-close protection remains in place while settling. Validation:
Retest artifact: /tmp/codeman-touch-tabs-prod-v8-20261101/report.json (runner, logs and screenshots alongside). The first production attempt stopped on a transient post-resize history classification; retained in attempt-1/. The completed run polls for the actual valid touch target up to 1.8 s without forced scrolling, forced clicks or programmatic focus. It still asserts keyboard dismissal releases focus. Native keyboard appearance remains unverified: Chromium touch events and viewport simulation prove web focus/state/input behavior, not the iPhone OS keyboard. Issue stays open and PR stays draft for device confirmation. Current GitHub Actions run 41298300037 is still in progress; local gates above passed. No upstream repository writes and no merge to local were made in this follow-up. |
|
Deployed candidate 8e2d26f, diagnostic build v9 (package 1.47.0). The fresh real-phone v8 reproduction disproved native resolution: release:true on dismissal, then later terminal focus remains active/onscreen/editable without a keyboard show; menu reflow followed by a tap succeeds. This is distinct from the earlier generation mismatch. Native trace is preserved privately at /tmp/codeman-35-v8-reloaded-phone.json. Candidate recovery: remember the exact input released on owned native dismissal. On a subsequent iOS opening gesture, while it is unfocused and the keyboard is hidden, temporarily remove and restore that input's display with synchronous layout reads before focus. Preserve the same DOM node, listeners, value, selection and original inline display/priority. A real keyboard show clears the marker. No focus retries from timers and no terminal resize, menu toggle or unrelated editor focus changes. This tests the layout-invalidation hypothesis suggested by the menu workaround; the native internal cause is not proven. Validation:
Artifacts: /tmp/codeman-touch-tabs-prod-v9-20261101/report.json, runner/log/screenshots alongside; /tmp/codeman-35-v9-{browser,unit,smoke,build}.log. Native acceptance remains pending: asked user to reload into v9 and reproduce. No v9 native beacon has arrived yet. Do not mark this resolved from Chromium emulation. Issue remains open and PR remains draft. GitHub Actions run 41303431017 is still in progress. No merge to local or upstream writes in this follow-up. |
|
Captured native failure and deployed 5ee9a00 (diagnostic v10; package 1.47.0) to production. Native evidence: fresh no-menu request-3 at 13:46:05 shows active, editable, rendered, clipped-in textarea, but document.hasFocus()=false immediately and at 350/1000 ms, with no keyboard show. In the same preserved trace request-2 from session-tab has pageFocus=true and does show the keyboard. Later menu-assisted request-19 also has pageFocus=true and a real viewport-show. Snapshot /tmp/codeman-35-v9-failure-no-menu.json is private (0600). This identifies missing page/window focus independently of activeElement; it does not prove a browser focus request will be accepted on the phone. Change: request window.focus() before focusing the terminal input when iOS reports the page unfocused. Gated on visible page plus active user gesture, and skipped for already-focused pages/non-iOS/background/no-gesture paths. No timers or loops retry focus; browser rejection is logged and the input gesture proceeds. Removed the unsuccessful v9 display/layout-rebuild method, dismissal marker and its tests. Diagnostic builds/boxes consistently identify v10 and log the page-focus request outcome. Validation:
Artifacts: /tmp/codeman-touch-tabs-prod-v10-20261101/report.json, runner/log/screenshots alongside; /tmp/codeman-35-v10-{browser,unit,smoke,build}.log. Asked user to reload into v10 and repeat without menu; if it fails, stop before menu to preserve the native page-focus outcome. Native acceptance pending; issue stays open and PR draft. GitHub Actions run 41313311244 is still in progress. No merge to local and no upstream writes. |
|
Deployed candidate 15dc142 (v11 diagnostics, package 1.47.0) after the native v10 failure. Evidence: at 15:17:11.505/11.804 the phone logs KEYBOARD_PAGE_FOCUS requested=true after=false. Request-13 stays DOM-focused but pageFocus=false and visible=false at 350/1000 ms. Menu close at 15:17:12.833 has pageFocus=true; request-14 then produces a real keyboard viewport-show. Private snapshot /tmp/codeman-35-v10-native-failure.json (0600). Script window.focus was ineffective on this phone. Change: remove script window.focus retries. For a visible iOS page that remains unfocused after an explicit terminal-input touch, arm a short-lived native-click recovery for the exact target, session and generation. Permit default browser activation on the following trusted compatibility mouse events while stopping propagation to xterm/CLI; refocus from its trusted click. Normal touch/selection mouse suppression remains. A new gesture, newer request, session switch, another editor, active selection, open keyboard or expiration prevents stale recovery. A content touch on an unfocused iOS page no longer pre-cancels that native activation path; actionable TUI taps still do not arm input recovery. OpenCode container capture skips only an armed recovery, retaining its ordinary click fallback. Validation:
Artifacts: /tmp/codeman-touch-tabs-prod-v11-20261101/report.json and runner/log/screenshots; /tmp/codeman-35-v11-{red,browser-final,unit-final,smoke,build-final}.log. User asked to reload into v11 and repeat without menu, stopping on failure if necessary. Native acceptance remains pending; issue stays open and PR stays draft. GitHub Actions run 41321387041 is still in progress. No merge to local and no upstream writes. |
fix(cases): enable default groups for new and linked cases
Mobile keyboard reopening can fail after dismissal even though xterm's input has DOM focus. The native phone traces show both failed and successful opens at the same onscreen editable input, so DOM focus alone is not an acceptance check.
This branch corrects the input lifecycle: a newly observed keyboard shrink owns an exact input and opening generation; dismissal releases only that owner and cannot cancel a newer request. Prompt taps that merely retain an already-open input preserve ownership. Actual opens and transfers supersede the old request. Touchstart releases remaining stale focus before touchend reopens input. Calibration survives same-width SSE listener reconnection, foreground recovery, and focus-out fallback. Existing explicit-tab, webview reveal, selection-guard and slow-load focus protections remain included. Diagnostic observers never focus or retry input and do not record typed contents.
Related #35. Latest candidate
2c5bc3eais deployed for native phone testing. Production servesmobile-handlers.bff5571d.js/terminal-ui.441447b5.js, byte-matching the isolated build. HTTP 200/service active; existing backend artifacts and unrelated WIP hashes unchanged. The issue remains open and this PR draft until the actual phone dismiss/reopen result is confirmed.Validation on this revision:
Chromium and mocked viewport changes verify event ordering, ownership and delivered input. They do not verify OS keyboard presentation. Claude authentication and external remote smoke are unavailable. Latest source RCA:
docs/reports/mobile-tab-keyboard/lifecycle-rca/dismiss-reopen-v7.md.