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?

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

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.