A fold change has to keep scroll position and input state

What it is

After the size jumps, the person is still on the same line and in the same field. Keeping scroll position and input state means folding or unfolding does not zero reading progress, drop uncommitted text, or dismiss the keyboard and selection in use. Layout may change from one pane to two. The task object, scroll offset, caret, and typed characters have to be the same instance of work. This is not “do not kill the process”—the process may rebuild; after rebuild it has to return to the same coordinate. Whether the hinge may hold content is a different question. This one is only whether the two ends of the jump are still connected.

Why it happens

A fold often triggers a configuration change: window metrics swap, the tree is torn down, a tree measured for the new size is mounted. The default path scrolls lists to 0, clears focus, and leaves uncommitted edits inside destroyed widgets. People remember “about this passage” and “I had typed half a sentence”—external memory plus working memory. Zeroed coordinates look like a refresh, or like a failed action. Input is more brittle: an IME composing buffer, a password field’s reveal toggle, a text selection, all live on a widget instance and vanish when the instance is replaced. A virtualized list also has to restore its data window; a saved pixel with a window reloaded from page one produces a blank or a wrong row. Media playback position and paged progress besides scroll belong to the same class of coordinates that must travel.

Studying it

Scroll a long list to the middle, type halfway into a field, leave the caret, then fold or unfold. Compare full restore, route-only restore without offset, and rebuild-to-top.

Independent variables: whether the UI is destroyed on the configuration change, restore by anchor (row id, character offset) versus by pixel, whether the IME buffer travels with the widget. Dependent variables: position error (row or character), lost typed text, whether focus remains in the original field, time to continue.

Do not only ask “same page?”—ask “same line, same character.” If the lab lets people submit before folding, uncommitted state is never measured. Do not collect taps during the fold animation; wait for stability before judging whether restore has finished, or an in-between frame will be scored as loss.

Where it stops holding

If content is rewritten during the fold (a new message inserted at top, a collaborator deleting the current row), exact pixels may be meaningless; scroll the original anchor back into view, and if the anchor is gone land on a neighbor and say so. One-shot search result lists must restore the query with the position, or the coordinate points at another hit set. If the user had deliberately returned to the top before folding, restoring the middle is wrong—save the state at leave, not a position the product prefers. A video that pauses because the decoder rebuilt with the surface should resume by itself; do not treat that pause as user intent.

Applying it

• Before a fold, record route, anchors (row id or character offset), uncommitted text, focused field, and playback position. After the new layout mounts, align to the anchor rather than writing back an old pixel value.
• Restore the virtualized window with the offset, so the view does not flash empty then jump.
• Write typed characters back into rebuilt fields and restore the caret. Do not clear uncommitted content in the name of a clean tree.
• Verify by scrolling to section N, typing half a sentence, then unfolding. The viewport should still contain section N, the half-sentence should remain, and focus should stay in that field. A jump to top, an empty field, or a need to refocus means the state did not travel.

Related

• Within the group: K3.03.1 Folding and unfolding are a live change of size · K3.03.3 The hinge must not hold anything the user has to read or hit
• Adjacent: G4.07 State Persistence and Position Restoration · G4.03 State Persistence · K1.08 App Switching and Background Reclamation
• Search terms: scroll restoration · configuration change · input state preservation