Skip to content

Navigation API scroll tests incorrectly assume that reloads will persist state #60113

@farre

Description

@farre

The spec path for reload scroll behavior:

NavigateEvent finish -> potentially process scroll behavior -> process scroll behavior step 3: for "reload" type, call restore scroll position data with the active session history entry.

Why there's nothing to restore:

save persisted state (which writes scroll position data to a session history entry) is only called from activate history entry, which is part of apply the history step -- the traversal path. A same-document reload via navigation.reload() + intercept() goes through commit a navigate event -> update the navigation API entries for a same-document navigation, which never calls save persisted state.

The #frag entry was created by navigate to a fragment (step 6), which creates a new session history entry without scroll position data. No subsequent operation saves scroll data to it. So when restore scroll position data runs after the transition, the entry has no data to restore from.

Contrast with push/replace: process scroll behavior step 4 calls scroll to the fragment for push/replace navigations -- that's why those tests correctly assert scrolling to #frag's current position. Reload never takes that path.

The fix: All four reload scroll tests should assert window.scrollY that equals the initial scroll position (0), since restore scroll position data with no persisted data restores to the default position rather than scrolling to the fragment.

Metadata

Metadata

Assignees

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions