riyadhafraa
5dac662421
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).