Mobile: audit, keyboard fixes that work, layout guards, and Playwright at phone width - #59
Merged
Conversation
… a tab bar that earns its slots THE KEYBOARD FIX DID NOT WORK — second attempt The first version compared window.innerHeight to visualViewport.height and assumed only the latter shrinks. On iOS both can, so the difference stayed near zero and the rule silently never applied — the tab bar went on covering the composer exactly as before. Now a focusin/focusout listener on text fields. Focus is a fact, not an estimate: the field either has it or it does not, on every browser, with no threshold to tune. The companion CSS rule was fragile in the same spirit — it targeted the generated Tailwind class by escaping every bracket of pb-[calc(3.5rem+env(safe-area-inset-bottom,0px))], a selector nobody can read and nothing verified. Replaced with a named pb-mobile-nav class. THE TAB BAR COVERED HALF THE TERMINAL Not the bar's fault: xterm listened to window.resize, which never fires when a mobile keyboard opens — the layout viewport is unchanged, only the visual one shrinks. So xterm kept its pre-keyboard height and its lower half sat behind the keyboard. Both TerminalPanel and ClaudePanel now listen to visualViewport resize AND scroll, since Safari also shifts the viewport when bringing a focused element into view without resizing anything. Same root error as the keyboard detection: measuring the wrong thing, and being confidently wrong because the measurement existed. THE TAB BAR SPENT ITS SLOTS BADLY Five slots is everything a phone gets. Browser and Scheduler held two of them. The browser tab is a CDP screencast of a 1920x1080 desktop Chrome scaled onto a 390px screen — you can see something is happening, you cannot read it. The scheduler is set-once admin and was already duplicated inside More. Meanwhile Tasks and Library — checking a board, moving a card, reading a note, the two most thumb-native things in the product — were buried under More. Now: Chat, Spaces, Tasks, Library, More. Browser moves INTO More, where it had never actually been listed, so removing it from the bar would have orphaned the panel. docs/mobile-audit.md records the whole audit: which panels are desktop-only in substance rather than layout, the recurring layout traps and which are now guarded by tests, why the keyboard is a first-class layout state, and what a phone-first version would look like. It also states plainly that none of it is verified on a device — every mobile bug that reached the user today was found by looking at a phone, and none would have been caught by any test in this repo. 39 frontend tests green, tsc clean.
…ting it Every mobile bug so far was found by a human looking at a phone, and none would have been caught here — jsdom has no layout engine, so it cannot tell you something is off-screen, clipped, or wider than the window. It cannot fail the way these bugs failed. @playwright/test was already a dependency, with a config and an e2e spec in the repo. I wrote "not verified on a device" five times without reaching for it. The assertions are the bugs that actually happened: - nothing wider than the viewport, and the failure NAMES the offending elements rather than just asserting false; - the document does not scroll sideways; - the tab bar exists and every button clears 40px; - a long unbreakable URL injected into a message does not widen the layout — the exact shape that caused the drift; - nothing is clipped without a scroller, which is the trace-summary sliver generalised: content taller than its box, inside overflow-hidden, with no scroller anywhere beneath it. Five pass against the live instance at iPhone 13 dimensions. The first run is the argument for taking screenshots: four checks "passed" while sitting on the projects page, because my helper looked for an href and the project card is a clickable div. They were measuring an almost-empty page and reporting success. The screenshot showed it in one glance. NOT covered, stated in the spec header: the on-screen keyboard. Playwright cannot summon one, so visualViewport never shrinks and the composer-hidden-by-the-tab-bar geometry stays device-only. Focus events fire, so the class toggle is checkable; what it exists to fix is not.
…caught
Working the mobile-audit punch list, item 2: encode the remaining traps as tests
rather than trusting the fixes to stay fixed.
TWO NEW GUARDS, AND WHAT THEY IMMEDIATELY FOUND
- vh on a mobile pane must be svh. On iOS vh is the LARGE viewport (as if
browser chrome were hidden), so an h-[85vh] modal is taller than the visible
area and its bottom edge is unreachable. The guard found TEN offenders across
six files — modals, previews, the workspace bottom sheet — every one a
composer-under-the-keyboard bug waiting for the right screen.
- Every window.resize listener must have a visualViewport companion, because
window.resize never fires when a mobile keyboard opens. The guard found the
modal Terminal variant — the SAME bug fixed in TerminalPanel hours earlier,
alive in a sibling file. That is the argument for guards in one line: the fix
is one panel, the guard is every panel including the ones not written yet.
THE SPACES HEADER ATE A QUARTER OF THE SCREEN
Found in my own Playwright screenshot rather than reported: at 390px, "New
Space" wrapped to two lines and "Show archived" to two more, so the header
consumed ~250px before any content. Labels now shrink to essentials on mobile
("New", an icon-only archive toggle with a title) and expand at md.
whitespace-nowrap throughout, because a wrapped button label is exactly how this
was discovered.
41 unit tests green, tsc clean, built. Playwright suite: 7 passing against the
live instance at iPhone 13 dimensions.
praxagent
added a commit
that referenced
this pull request
Jul 28, 2026
PR #59's description said the suite covered the keyboard chain — focus -> html.keyboard-open -> tab bar hidden -> padding released -> back on blur. It did not: I wrote these tests after committing the spec, ran them, quoted their results in the PR body, and never committed them. The five layout tests were in; the two keyboard tests existed only as an uncommitted local edit this checkout tripped over. So the PR claimed verification it did not carry. The tests themselves were real and passing — against the live instance, including the first-run failure where they targeted a tab with no composer — but a test that lives only in a working tree verifies nothing for anyone else. Both pass against the live instance.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Working the mobile punch list (
docs/mobile-audit.md), plus the verification loop that should have existed from the start.The keyboard fix — second attempt, the first didn't work
The viewport-arithmetic heuristic (
window.innerHeight - visualViewport.height > 150) failed on iOS, where the layout viewport can shrink too — the difference stayed near zero and the rule silently never applied. Now afocusin/focusoutlistener: focus is a fact, not an estimate. No threshold to tune.Same root error in the terminal: xterm listened to
window.resize, which never fires when a keyboard opens — only the visual viewport shrinks — so it kept a height that no longer fit and its lower half sat behind the keyboard. Terminal, Claude and modal-Terminal panels now listen tovisualViewport.The tab bar earns its slots
Was: Spaces · Chat · Browser · Scheduler · More.
Now: Chat · Spaces · Tasks · Library · More.
The browser tab is a CDP screencast of desktop Chrome scaled onto 390px — visible, not usable. Scheduler is set-once admin, already duplicated in More. Meanwhile the two most thumb-native surfaces were buried. Browser moves into More, where it had never been listed — removing it from the bar would have orphaned the panel.
Two new guards, eleven bugs on first run
vhmust besvhon mobile panes — on iOSvhis the large viewport, so anh-[85vh]modal is taller than the visible area with an unreachable bottom edge. Ten offenders in six files, all converted.window.resizelistener needs avisualViewportcompanion — found the modal Terminal carrying the exact bug fixed in TerminalPanel hours earlier. The fix is one panel; the guard is every panel, including ones not written yet.Playwright at a real phone viewport
e2e/mobile.spec.ts— iPhone 13 dimensions, real layout engine, runs against any instance viaBASE_URL. The assertions are the bugs that actually happened: nothing wider than the screen (failures name the offending elements), no sideways document scroll, 40px touch targets, the exact long-URL shape that caused chat drift, nothing clipped without a scroller, and the full keyboard chain — focus → class → bar hidden → padding released → back on blur.7 passing against the live instance. The first run is the argument for screenshots: four checks "passed" while sitting on the projects page because my selector was wrong — they were measuring an empty page and reporting success. The screenshot showed it in one glance. It also caught the Spaces header eating ~250px of a phone screen ("New Space" wrapped to two lines), fixed here.
Honest boundary
Playwright cannot summon a real keyboard, so exact keyboard-up geometry stays device-only. An Android emulator would close that, but this box has no
/dev/kvm— software emulation at 10–50× is not a loop. The audit records what remains hardware-only: keyboard geometry, touch feel, Safari quirks.41 unit + 7 e2e green, tsc clean. Deployed and verified on the live box.