Two Android-specific fixes:
1. Keyboard dismissing in main chat. App.tsx derives `mobileKeyboardOpen`
from useMobileKeyboard and uses it to gate the
`project-content--with-mobile-nav` / `--with-footer` className
assignment plus MobileNavBar rendering. When the soft keyboard opened
on Android, those classes were removed and the nav unmounted, shrinking
padding-bottom by ~80px in a single render. Android Chrome treats the
resulting jump of the focused chat input as the focus target moving and
instantly dismisses the keyboard. With interactive-widget=resizes-content
set on Android, the layout viewport itself shrinks with the keyboard, so
the hide-nav-on-keyboard pattern was redundant on Android (and harmful).
The whole pattern is now gated to iOS via isIOS(). iOS path is unchanged.
2. Pinch-zoom on kanban. Android Chrome ignores user-scalable=no for a11y,
and kanban's overflow-x:auto columns combined with the inflated ICB
produce a broken visual when the user zooms out. Adds
touch-action: pan-x pan-y to html,body inside the mobile media query
(keeps scroll panning, blocks pinch-zoom). Chat and MissionManager were
unaffected before because they don't expose a wide horizontal
scrollable region.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The body scroll-lock applied while the keyboard is up in main chat was an
iOS-specific workaround for visualViewport drift. On Android Chrome the same
mutation does the opposite of what we want — applying position:fixed to body
while the soft keyboard is opening causes Chrome to treat it as a focus-
target relayout and dismiss the keyboard instantly, making the main chat
composer unusable on Android.
useMobileScrollLock now early-returns on non-iOS user agents. Android Chrome
doesn't need it: with interactive-widget=resizes-content the layout viewport
shrinks with the keyboard, so there's no drift to compensate for.
Adds an Android-UA test case that asserts the lock is a no-op there.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
When App-level activation triggers the lock from an input gaining focus,
iOS may have already scrolled the document by the time the lock effect
runs. Capturing that already-shifted scrollY and restoring it on release
left the dashboard pushed up after the keyboard dismissed (the inline-
edit case). Always snap to 0 instead — the dashboard has body{overflow:
hidden} so user-initiated scroll is always 0 anyway, and any non-zero
value at lock time is iOS-forced and should be reset.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
- Add useMobileScrollLock hook using position:fixed body lock (Bootstrap/
Headless UI/Stripe pattern) to prevent iOS Safari from shifting the
document and visualViewport when an input inside a fixed-position modal
is focused. Wire into 15 input-bearing modals plus ChatView, replacing
ChatView's inline body-overflow effect.
- Widen computeBuildVersion in vite.config.ts to hash the entire app/ tree
so the version-check poll actually notices rebuilds (FN-3333 follow-up;
previously only main.tsx and package.json were hashed).
- ChatView: on input blur, suppress keyboard-aware sizing for 450ms while
reserving mobile-nav-bar space, so the composer snaps to its final
height in one move instead of crawling down with iOS's keyboard slide
and then jumping again when the nav bar reappears.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
