Bug 33571 – History traversals to a new document do not get the popstate event

• Status: RESOLVED
• Resolution: FIXED
• Component: Page Loading

[Brady Eidson]

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).

[Brady Eidson]

<rdar://problem/7536748>

[Brady Eidson]

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.

[Darin Adler]

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?

[Brady Eidson]

(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.

[Brady Eidson]

http://trac.webkit.org/changeset/53361

[Darin Fisher (:fishd, Google)]

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?

[Brady Eidson]

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).

[Darin Fisher (:fishd, Google)]

> 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!