Summary: | History traversals to a new document do not get the popstate event | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Brady Eidson <beidson> | ||||
Component: | Page Loading | Assignee: | Brady Eidson <beidson> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | fishd | ||||
Priority: | P2 | Keywords: | InRadar | ||||
Version: | 528+ (Nightly build) | ||||||
Hardware: | All | ||||||
OS: | All | ||||||
Attachments: |
|
Description
Brady Eidson
2010-01-12 20:06:07 PST
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. 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! |