Bug reportNov 12, 2026· 0:16· 11 views
SvelteKit 3.x: reloading a scrolled page paints at the top then jumps to the previous scroll position
0:16 total
Comments · 0
Be the first to comment.
Bug reportby SceneRecap AI
lowSvelteKit client router: reload scroll restoration (restore_reload_scroll) and the timing of history.scrollRestoration='manual' relative to first paint.
os: macOSdpr: 1url: /docs/kit/loadlocale: en-USbrowser: Chromium 151.0.7922.34timezone: Europe/Berlinviewport: 1280x720
Repro steps
- 1.Open /docs/kit/load (Loading data • SvelteKit Docs).
- 2.Scroll down 1700px three times, to the Universal vs server section where 'Input' is highlighted in the On this page list.
- 3.Reload the page with a full page navigation to /docs/kit/load.
- 4.Watch the scroll position at the load event and right after it.
Expected
After a reload, the page should come back at the previous scroll position (scrollY=5100) on first paint, with no visible state at the top of the page.
Actual
With scrollRestoration=manual, the browser does not restore scroll. The page is at scrollY=0 at the load event (11.5s). About 70ms later restore_reload_scroll moves it to scrollY=5100 (11.6s). This matches the reported paint at the top followed by a jump.
Evidence
consoleBefore reload: scrollY=5100, scrollRestoration=manual
visualBefore reload, the view shows the Output section and 'Input' is highlighted under Universal vs server.
consoleAfter reload (load event): scrollY=0. The browser did not restore scroll because scrollRestoration=manual.
consoleAfter restore_reload_scroll: scrollY=5100, back to Input section
visualThe final position after the reload matches the position before it: Output section view, 'Input' highlighted. The sampled frames do not capture the brief top-of-page state.
Issue markdown (copy-paste ready)
## Summary Reloading a scrolled SvelteKit docs page first sits at `scrollY=0`, then jumps back to the previous scroll position. ## Environment - Chromium 151.0.7922.34, macOS - Viewport 1280x720, DPR 1 - URL: `/docs/kit/load` ## Steps to reproduce 1. Open `/docs/kit/load` (0s). 2. Scroll down 1700px three times, to the Universal vs server / Input section (3.7s, 5.0s, 6.2s). 3. Reload the page (11.0s). ## Expected The page is restored at the previous scroll position (`scrollY=5100`) on first paint, with no jump. ## Actual - 8.0s: `Before reload: scrollY=5100, scrollRestoration=manual` - 11.5s: `After reload (load event): scrollY=0`. The browser did not restore scroll because `scrollRestoration=manual`. - 11.6s: `After restore_reload_scroll: scrollY=5100` The page is at the top at the load event, then jumps about 70ms later. The final position is correct (13s frame), but the sampled frames do not capture the brief top-of-page state. The console logs are the evidence for the jump. ## Suggested area Client router reload scroll restoration (`restore_reload_scroll`). Also check when `history.scrollRestoration='manual'` takes effect relative to first paint. *Recorded with SceneRecap.*
Your recordings could explain themselves too.
Free plan · silent recordings welcome · bug reports included.
Try SceneRecap free →