← React Viewport

Live Device Lab

Measuring…

Test React Viewport against your actual browser, software keyboard and screen geometry.

  1. Tap the input.
  2. Let the software keyboard open.
  3. Scroll this content while it is open.
  4. Rotate the device if available.
  5. Close the keyboard.

Expected behavior (check yourself): composer stays visible; geometry changes on open and returns on close.

Docked layout: content scrolls independently so long swipes do not pull the composer away from the keyboard.

The composer is fixed to the visible browser area. Scroll the content while typing.

Open the keyboard, then scroll this conversation. The geometry should follow your browser.

Try rotating the device. Close the keyboard and check that the bottom inset returns.

Messages stay on your device. Send clears the field; nothing is sent or saved.

Why did the demo not move?

Keyboard closed while a real keyboard is open? It may be a browser limitation or inference bug. Copy the geometry before, during and after opening. A browser that resizes both viewports may need no bottom inset.

Keyboard open, non-zero occlusion, but composer covered? That points to example positioning. Record the geometry and scroll/orientation steps, including the composer anchor.

Safe area still non-zero? WebKit can retain it while the keyboard is open. The layout subtracts the overlap with visual occlusion before applying safe-area padding.

Keyboard state is native where usable and otherwise conservatively inferred. Floating, split and hardware keyboards may produce no bottom occlusion. The composer also follows visual viewport size and offsets, even when keyboard inference is closed. In page-scroll stress mode, browser-delayed geometry can still cause movement during a fling.

DeviceLab.tsx · actual source
Composer.tsx · actual source