Browser behavior

If CSS solves it, don’t install React Viewport

This website requests interactive-widget=resizes-content. Supporting browsers resize both viewports for the keyboard. A CSS grid or flex layout may then be sufficient; zero bottom occlusion can mean the browser already made room.

The meta tag does not detect support. Current compatibility data lists Chrome and Firefox on Android as supporting this policy, and iOS WebKit as unsupported. Check browser compatibility. React Viewport does not set viewport policy or opt into VirtualKeyboard overlay mode.

Explore reactive geometry in the Geometry Lab. The CSS baseline is a secondary layout comparison.

For an occasional JavaScript read, use window.visualViewport directly. React Viewport is for shared, reactive geometry consumed by React. It reports state; the application decides whether to change rendering, hit tolerance, or scrolling.

Where each value comes from

Visual viewport

Native window.visualViewport supplies dimensions, layout-relative offsets, document-relative page coordinates, and scale when available. Otherwise, documented fallback geometry mirrors the layout viewport, uses window scroll for page coordinates, and reports scale 1.

Keyboard

A finite, positive native VirtualKeyboard intersection is used when usable. Otherwise, conservative focused-editable and visual-occlusion evidence may infer keyboard state. The result is normalized to bottom-edge occlusion.

Safe area

A hidden CSS probe reads all four env(safe-area-inset-*) values. These remain raw measurements; CSS should consume env() directly when layout is the only need.

Read the labels literally

Supported

The current runtime exposes an API the package can detect. This says nothing about active browser mode or physical-device validation.

Tested

A deterministic repository scenario covers the behavior.

Fallback

The package supplies documented geometry when an API is absent.

Native geometry has narrow authority

The W3C VirtualKeyboard specification defines boundingRect as the intersection of the virtual keyboard with the document viewport in client coordinates. The package treats a finite, positive-area intersection as native evidence that the keyboard is open.

supported.virtualKeyboard reports API availability. Capability presence is not proof that overlay mode is active: the library never sets overlaysContent, calls show(), or calls hide().

Height remains a bottom-occlusion value. A native floating rectangle can intersect the viewport without touching its bottom edge, producing { open: true, height: 0 }. Open and zero bottom occlusion are therefore compatible, not contradictory.

A bottom-attached partial-width rectangle still yields a scalar bottom inset. That scalar cannot represent segmented or arbitrary-shape avoidance, so consumers needing two-dimensional avoidance must use a richer layout policy.

Keyboard inference is conservative

Without native Virtual Keyboard geometry, inference requires a focused editable element, no active zoom, and visual-bottom occlusion of at least the larger of 80 CSS pixels and 15% of layout height. Focus alone is never reported as an open keyboard.

Compose bottom constraints with the larger value

Keyboard occlusion and safe-area insets remain raw, independent measurements. Use Math.max(keyboard.height, safeArea.bottom) for a single bottom constraint; adding them can count the same covered edge twice.

Upstream WebKit bug 217754 records safe-area-inset-bottom remaining set after a software keyboard appears. That report explains why a raw safe-area value may be stale in this state. It is upstream evidence, not a physical-device result from this project, and the package adds no browser-specific runtime workaround.

Automated evidence

Open the Geometry Lab to record before, during and after keyboard geometry. Capability flags, safe-area values and keyboard inference are shown independently. No single “supported” badge can establish all of them.

The 2026-09-06 deterministic baseline passed 54 library scenarios and 102 documentation-site scenarios across desktop Chromium, Firefox, and WebKit. These fixtures establish repository behavior only; they are not physical-device results.

• Library browser suite
• Website browser suite
• Current readiness report

Environment notes