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 "/"
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
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
(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?
(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.
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.
(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?
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 :)
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
Created attachment 159969 [details] empty-document-goes-back.html
Created attachment 159970 [details] assign-after-pushstate.html
Created attachment 159971 [details] test.html
Created attachment 159973 [details] cute puppy image
Created attachment 159975 [details] cute puppy image
Created attachment 159976 [details] test.html
Comment on attachment 159976 [details] test.html I think this live test can be used to reproduce the behavior seen in Josh's video.
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.
FYI this is a duplicate of Bug 80697. https://bugs.webkit.org/show_bug.cgi?id=80697
Agreed. *** This bug has been marked as a duplicate of bug 80697 ***