666792 - Docshell should set scroll position after running popstate event

Status: RESOLVED WONTFIX

(Core :: DOM: Navigation, defect)

Description

[Spines11]

User-Agent:       Mozilla/5.0 (Windows NT 5.1) AppleWebKit/534.30 (KHTML, like Gecko) Chrome/12.0.742.100 Safari/534.30
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0) Gecko/20100101 Firefox/4.0

If a website uses the HTML5 history API, and the page length of the previous page is longer than the page length of the current page, the scroll location will be too high up when the user presses the back button.

This is because the scrolling to the user's position on the previous page happens before a website gets to handle the popstate event.  So, when they hit the back button, firefox scrolls to their previous position, but if the page is currently too short, it will only scroll down that far.

The solution to this, (and the way it works in Google Chrome), is to wait to scroll to the position on the previous page, until after the popstate event has been handled.  The popstate event is where the developer sets the content of the page, and so it should wait for the content to actually be there before trying to scroll.

Reproducible: Always

Steps to Reproduce:
1. See above description.
2.
3.

Comment 1

[Justin Lebar (not reading bugmail)]

Thanks for the bug report.  I'll look into this.

Comment 2

[Justin Lebar (not reading bugmail)]

I think this is bugged in the spec.  At [1], step 9 is scrolling, while popstate isn't fired until step 12.

[1] http://www.whatwg.org/specs/web-apps/current-work/#history-traversal

Comment 3

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I don't really understand why scrolling after popstate is better. Doesn't that make it harder for the page to update the scroll position as part of the page transition code?

Justin, I'm also not fully understanding what you're saying. Are you saying that we're following the spec but you think the spec is wrong? Or that we're not following the spec but you think we should?

Comment 4

[Spines11]

@Justin - Ah, didn't realize the order was specified in the spec.  Best to follow the spec.

@Jonas - If you scroll before popstate, then the client side code has to handle the logic to scroll back to the correct spot itself. I don't know of an easy way to know what scroll position you should go to in the popstate event.   

But you're right, if it's done after the popstate event, then any change to the scroll you do in the popstate event handler is undone.

Comment 5

[Justin Lebar (not reading bugmail)]

> Are you saying that we're following the spec but you think the spec is wrong? 
> Or that we're not following the spec but you think we should?

We're following the spec, but I thought the reporter had a good point that the spec is wrong.

> Doesn't that make it harder for the page to update the scroll position as part 
> of the page transition code?

This, however, is also a good point.

(In reply to comment 4)
> I don't know of an easy way to know what scroll position you should go to in 
> the popstate event.

This is tricky.  You can save the scroll position in the state object, but by the time the popstate event fires, it's too late -- you can't modify the previous state any longer.

You could listen to window.onscroll and update history.state, but this kind of makes me wonder why we don't have a "state unloaded" even to go along with the "state loaded" event.

Comment 6

[Justin Lebar (not reading bugmail)]

> Doesn't that make it harder for the page to update the scroll position as part 
> of the page transition code?

I think we're going to wontfix because fixing would make it much more difficult for pages to legitimately scroll the user around.