658448 - Scroll positions are not always restored when you navigate forward / backward multiple pages

Status: NEW

(Core :: DOM: Navigation, defect)

Description

[Justin Lebar (not reading bugmail)]

As we discovered in bug 653741 comment 19, if I visit

 * A.html
 * A.html#1
 * A.html#2
 * B.html

then go back 2 (taking me to A.html#1), I'm taken to the top of the page.

AIUI, there are currently two mechanisms for saving and restoring scroll position.

SHEntries may have a saved layout state.  (Bug 646641 makes this saved layout state shared between all the SHEntries for a given document.)  When we navigate from an SHEntry for document A to an SHEntry for document B, we restore the saved layout state, and thus restore the scroll position.

In the test case above, when we navigate from B.html to A.html#1, the SHEntry for A.html#1 doesn't have a saved layout state, since we only saved it when we navigated to A.html#2.  Again, this will be different once bug 646441 lands.

But it still won't be right.  We saved the layout state for A.html#2, but we need to restore the scroll position for A.html#1.

The natural solution is to always restore the scroll position in an SHEntry when we load it.  But we also need to make sure that we always save an SHEntry's scroll position when we deactivate it -- right now, we rely on the saved layout state to hold that data for the SHEntry we were on when we finally navigated to a different document.

I'd love to get rid of the scroll position from the saved layout state altogether, but bz has a pathological case in bug 653741 comment 24.  But maybe we can get to the point where we only use the saved layout state's scroll position when handling pathologies (pathogens?).

Comment 1

[Boris Zbarsky [:bzbarsky]]

I think not restoring scroll position from the layout state on document navigation is just fine.  We might just need to pass around a boolean indicating who's doing the restoring.