Rotation must keep scroll position and input state

What it is

You are sixty percent through an article; rotate; you are back at the title. A checkout is half filled; rotate; the keyboard dies, focus dies, the field sits under the new keyboard. If orientation is implemented as a fresh navigation, scroll pixels and input do not survive. Rotation has to keep where you were and what you were typing, not start a new match.

How reach changes is the previous leaf’s geometry. This one only asks whether state lived through the relayout.

Why it happens

Orientation is often a full view-tree rebuild, especially when portrait and landscape are different trees. Scroll offset is a pixel y in the old layout; the tree goes, the y goes. Survival needs a content identity as the anchor: still looking at this row, caret still at character n of this field — not “1840 px from the top.” Input lives in components that get torn down; unless it is extracted and poured back, it is gone.

Keyboard plus rotation is worse: the new layout has a different visible height, the old “scroll out from under the keyboard” compensation is stale, and the focused field is covered. Modals, playback time, multi-select sets are the same class of state that has to move house, not décor.

Where it stops holding

When portrait and landscape are genuinely different apps (camera finder vs gallery, game level vs menu), a reset may be intended. Even then, the clip you were recording and the note you were typing should not vanish. A web page that reloads on orientationchange cannot keep state by layout tricks; that is architecture.

A first screen with no scroll and no input does not care. Tools, reading, forms, media are the blast zone.

Applying it

• Restore by content anchor: lists remember the first visible id, documents a ratio or block id, forms the focused field and caret.
• Do not unmount the field being edited on rotate. If the system dismissed the keyboard, put focus back and re-run scroll compensation after the turn.
• How to check: scroll a list ~60%, type uncommitted text in a field, open a modal, rotate both ways and back. The same row should still be in view, the text and caret still there, the modal still open. Any loss: find which layer rebuilt without writing state back. Rotate once more with the keyboard up and confirm the focused field is still visible above it.

Related

• Same group: F2.13.1 Landscape rewrites reach and kills one-handed use · F2.13.3 Locking orientation needs a hard reason
• Nearby: F1.10 Keyboard compression of the viewport · F2.11 Fluid and adaptive layout · F1.06 Positional stability of frequent actions
• Search terms: orientation change · scroll restoration · caret · view state