Task #476. On iPad Safari, opening the keyboard while writing a new
note or replying inside the note thread dialog covered the bottom of
the dialog (textarea + send button). The dialog used
`top:50%; translate(-50%,-50%)` against the layout viewport and never
reacted to the visual viewport shrinking when the keyboard appeared.
Changes:
- artifacts/tx-os/index.html: added `interactive-widget=resizes-content`
to the viewport meta so iOS 17+ resizes the layout viewport when the
software keyboard opens.
- artifacts/tx-os/src/hooks/use-visual-viewport.ts: new hook that
subscribes to `window.visualViewport` `resize` / `scroll` /
`orientationchange` events (rAF-throttled) and exposes the current
visible height plus the bottom keyboard inset.
- artifacts/tx-os/src/components/ui/dialog.tsx: `DialogContent` now
reads the hook and, when the keyboard inset is non-trivial (> 80px),
pins its center to the visible viewport mid-line and caps
`max-height` to the visible height. Desktop renders unchanged
(inset is 0 → no inline style applied beyond what the caller passes).
- artifacts/tx-os/src/pages/notes.tsx: the thread dialog reply
textarea and the top composer textarea now `scrollIntoView({ block:
"center" })` on focus (after a 250ms delay so the keyboard animation
settles), so the cursor lands inside the visible region on touch
devices. Desktop focus is unaffected — `scrollIntoView` is a no-op
when the element is already in the viewport.
Verification:
- `tsc --noEmit` clean.
- Existing `notes-thread-dialog` e2e still passes (dialog stays
capped at 85% viewport height, scroller still overflows, recipient
chips and composer remain in viewport).
riyadhafraa
5dac662421