Visual Viewport, Keyboard, and Focused Input

Working case

A reviewer opens a modal note editor on a phone and focuses the last field. The keyboard appears, leaving only part of the editor visible. The modal content scrolls within the remaining space, while the save action stays reachable without covering entered text. When the keyboard closes, the layout returns without a large blank gap. If the phone is zoomed or rotated, the editor still exposes a close control and focus remains in the modal. A return to the activity feed restores focus to the edit trigger, not a hidden footer.

Implementation boundary

Start with flexible block sizing, safe-area-aware spacing, and a scrollable modal body. Use visual-viewport measurements only when the target-browser behavior requires them; detect the API and clean up resize and scroll listeners. Read measurements in a batched step and avoid changing many layout properties for every keyboard animation frame. Do not force scroll on every input event, because it can fight the browser’s own focus scrolling. Test with hardware keyboards too: a missing on-screen keyboard should not leave an artificially short editor.

function usableEditorHeight(visibleHeightPx, reservedControlsPx) {
  return Math.max(240, visibleHeightPx - reservedControlsPx);
}
console.log(usableEditorHeight(510, 126));
// Output: 384

Cost and tradeoffs

Reading a viewport dimension is O(1), but repeatedly measuring layout and writing heights during rapid resize can trigger costly recalculation. CSS-based flexible sizing reduces script work but may need browser-specific verification. An always-fixed action bar is visually convenient until it obscures the active field or traps the user; making the content scrollable may be safer. Measure field visibility, action reachability, layout shifts, and focus return under keyboard open, close, rotation, zoom, and route transition. Do not infer success from one emulator screenshot.

Failure trace

A modal sets height to a fixed 620 pixels and pins Save to the bottom of the layout viewport. On a small phone the keyboard covers Save, and the modal body cannot scroll. Replace the fixed height with a bounded flexible layout and test the visible region while typing. Another fix listens to visualViewport resize but never removes the listener, so repeated modal openings cause multiple competing measurements. Open and close repeatedly, rotate, zoom, connect a hardware keyboard, and test a browser without visualViewport support. Confirm focus is never sent behind the modal.

Decision note

Design for the visible space the person has while typing. Use browser viewport signals as measured input, with a CSS-first fallback and a focus contract that survives keyboard changes.

Verification

• Complete the primary case with the capability available and with it denied or absent.
• Interrupt the interaction during its pending state and confirm no stale resource, focus, or scroll state remains.
• Check that server authorization and validation still hold after the browser interaction.

Common Mistakes

• Assuming keyboard height is constant across devices.
• Fixing the action bar over the active field.
• Leaving visual-viewport listeners active after the editor closes.

Connected lessons

Overlays, Scroll, and Mobile Viewport; Stacking Context, Top Layer, and Overlay Contract; Scroll Containers, Anchoring, and Chaining; Pointer Gesture, Touch Action, and Alternate Control; Dialog Focus and Interruption Boundary; Route Scroll and Focus Restoration; Responsive interaction: preserve content and control order.

Apply and check

Build Project: mobile review overlay and scroll and review Web Development: browser capability and viewport decisions quiz.