By default, what does a browser do to the scroll position when the user presses Back, and what does setting history.scrollRestoration to 'manual' change for a single-page app?

## What the default does Every session history entry carries a scroll position alongside its URL and state. With `history.scrollRestoration === 'auto'` — the default — the browser saves the offset as you leave an entry and reapplies it when you traverse back. On a classic multi-page site this is invisible and correct: the document is reconstructed to its full height before the restore, so the offset is meaningful. ## Why it misfires in a single-page app The SPA sequence is out of order: 1. The user presses Back. 2. The browser traverses to the previous entry and tries to restore its scroll offset — but the **document has not changed**. The DOM on screen is still the short detail page. 3. `popstate` fires. 4. Your router renders the long feed. At step 2 the requested offset (say 4200px) exceeds the current scrollable height, so it is clamped — usually to 0. By the time the tall content exists at step 4, the browser considers the restore done. The user lands at the top of a feed they had scrolled halfway through, which is one of the most-reported SPA complaints. ## Taking over ```js if ('scrollRestoration' in history) { history.scrollRestoration = 'manual'; } ``` The property is an attribute of the current session history entry, not a global switch, so routers set it during startup and re-assert it as they create entries. Reading it back is also the feature detection — an engine without support simply will not have the property. Then the router does the bookkeeping. Save on the way out, restore after render: ```js const offsets = new Map(); function navigate(path) { offsets.set(history.state.key, window.scrollY); // before leaving history.pushState({ key: crypto.randomUUID(), path }, '', path); render(); window.scrollTo(0, 0); // new views start at the top } window.addEventListener('popstate', (e) => { render(location.pathname); const y = offsets.get(e.state?.key) ?? 0; requestAnimationFrame(() => window.scrollTo({ top: y, behavior: 'instant' })); }); ``` Two details carry the whole thing. **Restore after layout**, not immediately: `scrollTo` against a document that has not yet grown to full height clamps exactly as the browser's own attempt did, so schedule it after the new content is in the DOM and measurable. **Use `'instant'`**, not smooth — a Back press should feel like arriving, not like an animation, and a smooth scroll can be interrupted by the user. ## The hard cases **Asynchronous content.** If the restored view fetches its items, the correct height does not exist for hundreds of milliseconds. A single post-render `scrollTo` is not enough. Options: reserve the height by caching the previous render or by keeping placeholder skeletons of the right size; or retry the restore once the list reports its final height, for example from a `ResizeObserver` on the scroll container, and stop as soon as the user scrolls themselves so you never fight their input. **Virtualized lists.** The scroll offset is meaningless because item heights are estimated. Persist the first visible item's identifier instead of pixels, and have the list scroll that item into view on restore. **Nested scroll containers.** `window.scrollY` covers only the document scroller. A pane with `overflow: auto` has its own `scrollTop`, which nothing restores for you; record and restore each container you care about. **Where to keep the offsets.** A module-level `Map` keyed by the entry's state key is simple but dies on reload. Putting the offset into the history state itself with `replaceState` makes it survive a reload and session restore, at the cost of a history write on every scroll-away — debounce it. Cross-tab persistence in `sessionStorage` is a third option, keyed the same way. ## Whose job is this anyway Every mature router — and the browser's own newer navigation machinery — ships some version of this. If you are using one, the interview answer is knowing *what it is doing on your behalf* and where its assumptions break: async content, virtualization, and nested scrollers are precisely where a framework's built-in restoration stops being enough and you have to reach for the primitives above.