Bug 93506 - History state is incorrect attached to new document when loaded via location.assign or location.replace
: History state is incorrect attached to new document when loaded via location....
Status: RESOLVED DUPLICATE of bug 80697
: WebKit
History
: 528+ (Nightly build)
: All All
: P2 Normal
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2012-08-08 12:38 PST by
Modified: 2014-02-19 07:48 PST (History)


Attachments
Layout test cases (2.66 KB, patch)
2012-08-08 12:38 PST, Joshua Peek
no flags Review Patch | Details | Formatted Diff | Diff
empty-document-goes-back.html (125 bytes, text/html)
2012-08-22 11:13 PST, Adam Roben (:aroben)
no flags Details
assign-after-pushstate.html (710 bytes, text/html)
2012-08-22 11:14 PST, Adam Roben (:aroben)
no flags Details
test.html (561 bytes, text/html)
2012-08-22 11:20 PST, Adam Roben (:aroben)
no flags Details
cute puppy image (61 bytes, url)
2012-08-22 11:22 PST, Adam Roben (:aroben)
no flags Details
cute puppy image (23.78 KB, image/jpeg)
2012-08-22 11:23 PST, Adam Roben (:aroben)
no flags Details
test.html (571 bytes, text/html)
2012-08-22 11:24 PST, Adam Roben (:aroben)
no flags Details


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2012-08-08 12:38:12 PST
Created an attachment (id=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 "/"
------- Comment #1 From 2012-08-16 23:09:57 PST -------
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
------- Comment #2 From 2012-08-17 08:20:34 PST -------
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
------- Comment #3 From 2012-08-17 09:30:30 PST -------
(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?
------- Comment #4 From 2012-08-17 09:31:08 PST -------
(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.
------- Comment #5 From 2012-08-17 09:47:14 PST -------
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.
------- Comment #6 From 2012-08-17 09:54:00 PST -------
(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?
------- Comment #7 From 2012-08-17 10:06:35 PST -------
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  :)
------- Comment #8 From 2012-08-20 12:55:15 PST -------
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
------- Comment #9 From 2012-08-22 11:13:01 PST -------
Created an attachment (id=159969) [details]
empty-document-goes-back.html
------- Comment #10 From 2012-08-22 11:14:06 PST -------
Created an attachment (id=159970) [details]
assign-after-pushstate.html
------- Comment #11 From 2012-08-22 11:20:39 PST -------
Created an attachment (id=159971) [details]
test.html
------- Comment #12 From 2012-08-22 11:22:25 PST -------
Created an attachment (id=159973) [details]
cute puppy image
------- Comment #13 From 2012-08-22 11:23:47 PST -------
Created an attachment (id=159975) [details]
cute puppy image
------- Comment #14 From 2012-08-22 11:24:33 PST -------
Created an attachment (id=159976) [details]
test.html
------- Comment #15 From 2012-08-22 11:25:32 PST -------
(From update of attachment 159976 [details])
I think this live test can be used to reproduce the behavior seen in Josh's video.
------- Comment #16 From 2012-08-22 12:10:30 PST -------
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.
------- Comment #17 From 2012-08-29 21:03:36 PST -------
FYI this is a duplicate of Bug 80697.

    https://bugs.webkit.org/show_bug.cgi?id=80697
------- Comment #18 From 2014-02-19 07:48:26 PST -------
Agreed.

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