Bug 93506 – History state is incorrect attached to new document when loaded via location.assign or location.replace

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: History

[Joshua Peek]

Created attachment 157271 [details]
Layout test cases

To reproduce, load an initial document, then call history.pushState({foo:true}, "", url) to set a new url. Calling location.assign or location.replace with the new current url will correctly reload a new document. But the history state associated with the document is incorrect. `event.state` will be `{foo:true}` instead of `null` and pushing the back button will cause a pop state event instead of loading the previous document.

    # URL: /
    history.pushState({foo:true}, "", "/other.html")
    location.assign("/other.html")

    # URL: /other.html
    event.state # => {foo:true} should be null
    history.back() # => causes popstate instead of loading "/"

[Balaji N.V.]

Are you accessing the event.state in the popstate event handler? I am trying to access event.state from postate event handler, and the problem is not reproducible. Is it possible to attach another test case which can be used as it is.

Thanks

[Joshua Peek]

There shouldn't be a popstate event on the second page. It should be a hard load back to the previous page. Thats the bug. Can you view the automated case I posted? It passes in Firefox.

(In reply to comment #1)
> Are you accessing the event.state in the popstate event handler? I am trying to access event.state from postate event handler, and the problem is not reproducible. Is it possible to attach another test case which can be used as it is.
> 
> Thanks

[Brady Eidson]

(In reply to comment #2)
> There shouldn't be a popstate event on the second page. It should be a hard load back to the previous page. 

This is inaccurate and is expected behavior.

There is always a popstate event.

Checkout "5.9.3 Activating state object entries" of HTML5.  Or for much more colloquial conversation about it check out the mozilla dev network's explanation - https://developer.mozilla.org/en-US/docs/DOM/window.onpopstate

How does your test case behave in Firefox?

[Brady Eidson]

(In reply to comment #3)
> (In reply to comment #2)
> > There shouldn't be a popstate event on the second page. It should be a hard load back to the previous page. 
> 
> This is inaccurate and is expected behavior.
> 
> There is always a popstate event.

To clarify - there is always a popstate event *when traversing the session history*.  There should not be one on new page loads.

[Joshua Peek]

Sorry, its really not about the popstate event itself then.

Whats the technical language for when the Back button actually loads a new document vs only firing a popstate event?

The bug is anytime you do history.pushState({}, "", "/newurl"), then attempt to renavigate to the same url again. The back button gets into a strange state.

I guess, my exception is that anytime you reload a document, it should have its own session history.

[Brady Eidson]

(In reply to comment #5)
> Sorry, its really not about the popstate event itself then.
> 
> Whats the technical language for when the Back button actually loads a new document vs only firing a popstate event?

Pressing the back button is "traversing the session history."

And whether or not that means moving to the previous fragment scroll for the current document, *only* popping a previously pushed state, or navigating to a completely different document... there is always a popstate event.

> I guess, my exception is that anytime you reload a document, it should have its own session history.

This is false.  Reloading the current document replaces the current item in the session history, but doesn't affect anything else.

I ask again - What happens in other browsers?

[Brady Eidson]

I'm sorry, I just noticed that you already commented it passes in Firefox.  It was at the end of a long line that scrolled off my screen  :)

[Joshua Peek]

Sorry, I still think I'm not getting the terminology quite right. I made a quick video to help demonstrate. And it actually doesn't seem to be limited to `location.assign` or `location.replace`. It happens anytime you navigate to the url, even with a click.

Video: http://cl.ly/3P0V2o3W2g0t
Source: https://gist.github.com/3407127

[Adam Roben (:aroben)]

Created attachment 159969 [details]
empty-document-goes-back.html

[Adam Roben (:aroben)]

Created attachment 159970 [details]
assign-after-pushstate.html

[Adam Roben (:aroben)]

Created attachment 159971 [details]
test.html

[Adam Roben (:aroben)]

Created attachment 159973 [details]
cute puppy image

[Adam Roben (:aroben)]

Created attachment 159975 [details]
cute puppy image

[Adam Roben (:aroben)]

Created attachment 159976 [details]
test.html

[Adam Roben (:aroben)]

Comment on attachment 159976 [details]
test.html

I think this live test can be used to reproduce the behavior seen in Josh's video.

[Adam Roben (:aroben)]

Here's the bug as I see it based on test.html:

1. Click "Run JS"
2. Click either of the two links on the page
3. Click Back

The URL changes back to the test page, but instead of showing the test page again you just continue to see the puppy picture.

If you perform the same steps in Firefox, you end up back on the test page.

Brady, which behavior seems correct to you? Firefox's makes more sense to me, but I'm no expert in this pushState stuff.

[Sean Hogan]

FYI this is a duplicate of Bug 80697.

    https://bugs.webkit.org/show_bug.cgi?id=80697

[Adam Roben (:aroben)]

Agreed.

*** This bug has been marked as a duplicate of bug 80697 ***