History traversals to a new document do not get the popstate event. In http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#the-history-interface in section 6.11.9 step 10 the spec states: "If the specified entry is a state object or the first entry for a Document, the user agent must activate that entry." The *only* session history traversal that does *not* meet these requirements are fragment scrolls without state objects. Basically the spec is saying that any time you go back or forward any number of steps and the resulting navigation creates a new document, you should get a popstate event (even if the state object is null).
<rdar://problem/7536748>
Created attachment 46729 [details] Patch v1 After transitioning to committed, set a pending state object in the FrameLoader based on the current history item. It will then pass it on to any new Document that is later created for this Frame load. Previous layout tests are updated to cover the new behavior.
Comment on attachment 46729 [details] Patch v1 Are there security implications to letting these state objects cross document boundaries? What prevents them from crossing security origin boundaries?
(In reply to comment #3) > (From update of attachment 46729 [details]) > Are there security implications to letting these state objects cross document > boundaries? What prevents them from crossing security origin boundaries? My understanding of the HTML 5 structured clone algorithm in general and SerializedScriptValues more specifically is that they are safe to be used in this manner. Certainly that the push/replaceState() API uses them in this manner implies that is the case. Note that when a script does a push/replaceState() with a URL argument, they cannot change the URL outside of their security origin, so even when a new document later takes hold of the cloned object there's still some semblance of same-origin based security.
http://trac.webkit.org/changeset/53361
Perhaps it would be nicer to store the pending state object on the DocumentLoader so that it doesn't have to exist on both FrameLoader and Document?
I didn't consider that approach because the Frame->Document and FrameLoader->DocumentLoader relationships are (sadly) not the same, and not updated at the same times. While it is possible your suggest would end up working out, I can imagine at least a few scenarios where it might not be safe or correct. I'm not convinced it's worth the effort to verify that would be sound (largely because the patch has already landed).
> While it is possible your suggest would end up working out, I can imagine at > least a few scenarios where it might not be safe or correct. I'm not convinced > it's worth the effort to verify that would be sound (largely because the patch > has already landed). Really? It seems unfortunate to have two places where we store a pending state object. I'll file a bug about this so we don't forget about it. https://bugs.webkit.org/show_bug.cgi?id=33992 It'd be great if you could share those problematic scenarios. Thanks!