FB IAB on Xiaomi (and similar WebViews that don't shrink 100dvh) keeps
the chat input covered by the soft keyboard. Fix by writing the
visualViewport-derived keyboard height to a CSS variable on <html> and
consuming it as padding-bottom on the chat input bar.
- Add useKeyboardHeight hook (visualViewport + rAF batching, no re-renders)
- Apply --keyboard-height + env(safe-area-inset-bottom) to .bar padding
- Add scrollIntoView on textarea focus so the input stays visible
- Add viewportFit: cover so safe-area-inset-bottom is reported
The three defensive Zod helpers (stringOrEmpty, numberOrZero,
booleanOrFalse) used by user.ts are general-purpose Zod utilities
that any schema may need — they're not user-specific. The original
inline declaration in user.ts had two downsides:
1. Any new schema (chat, auth, metrics, etc.) that needs the same
'null | undefined → default scalar' pattern would have to
duplicate the helper.
2. The long defensive-parse comment block (11 lines) lived inside
user.ts and didn't explain the helpers' general purpose.
Move them to src/data/schemas/nullable-defaults.ts (top-level
sibling of auth/, chat/, metrics/, user/ subdirs) so any schema
can import them. Keep the original explanation verbatim at the
top of the new file.
Bundled in this commit:
- user.ts imports the helpers from the new file (drops 11 lines
of comment + 3 const declarations)
- 3 auto-generated barrel index files regenerated by barrelsby
to pick up the new exports (chat/, subscription/, stores/user/)
The previous install flow had a timing race: the
`beforeinstallprompt` event fires at unpredictable times after
page load (often ~30s+ into the session, when Chrome's heuristic
finally decides the user is engaged). If the listener was
attached only inside the dialog's onClick handler, by the time
the user clicked OK the event had already fired into the void
and the deferred prompt was null — so `install()` returned
"unavailable" every time.
The new flow attaches the listener as early as possible:
1. `pwaUtil.prepareInstallPrompt()` — new public method that
calls the private `attachListener()`. Idempotent (guard via
`listenersAttached`).
2. `pwaUtil.canPromptInstall()` — companion getter that returns
whether a deferred event is currently cached. Useful for UI
to decide whether to even show the install CTA.
3. `pwa-install-overlay.tsx` — calls `prepareInstallPrompt()`
right after the isSupported / isInstalled guards. The overlay
mounts when the user enters /chat, so this is the earliest
practical point in the user flow.
4. `pwa-screen.tsx` — calls `prepareInstallPrompt()` BOTH at
module load (synchronous, so the listener is attached before
the splash screen's useEffects run) AND in a useEffect for
robustness. The splash screen is the very first screen the
user sees, so attaching here is the earliest possible.
5. `pwa-install-dialog.tsx` — `handleInstall` is now async,
and `onInstall` accepts `() => void | Promise<void>`. The
overlay calls `await pwaUtil.install()` so the deferred
prompt flow can complete before the dialog unmounts.
Together: the listener is now attached from the moment the
splash screen module loads, the deferred prompt is captured
whenever Chrome decides to fire the event, and the dialog's
install button can reliably `prompt()` against the cached
deferred. The full install flow now works end-to-end.
admin