a578cc8192
### What? While scrolled on a page, and when following a link to a new page and clicking the browser back button or using `router.back()`, the scroll position would sometimes restore scroll to the incorrect spot (in the case of the test added in this PR, it'd scroll you back to the top of the list) ### Why? The refactor in #56497 changed the way router actions are processed: specifically, all actions were assumed to be async, even if they could be handled synchronously. For most actions this is fine, as most are currently async. However, `ACTION_RESTORE` (triggered when the `popstate` event occurs) isn't async, and introducing a small amount of delay in the handling of this action can cause the browser to not properly restore the scroll position ### How? This special-cases `ACTION_RESTORE` to synchronously process the action and call `setState` when it's received, rather than creating a promise. To consistently reproduce this behavior, I added an option to our browser interface that'll allow us to programmatically trigger a CPU slowdown. h/t to @alvarlagerlof for isolating the offending commit and sharing a minimal reproduction. Closes NEXT-1819 Likely addresses #58899 but the reproduction was too complex to verify. |
||
---|---|---|
.. | ||
assertion | ||
external-push/[storageKey] | ||
hash | ||
hash-changes | ||
hash-link-back-to-same-page | ||
hash-link-to-pages-router | ||
hash-with-scroll-offset | ||
mpa-nav-test | ||
nested-navigation | ||
nested-relative-query-and-hash | ||
not-found | ||
redirect | ||
redirect-dest | ||
router | ||
scroll-restoration | ||
search-params | ||
layout.js | ||
page.js |