Repository navigation
Request for snapshotting initiator base URL #197
Description
WebKittens
Title of the spec
Snapshotting initiator base URL
URL to the spec
URL to the spec's repository
No response
Issue Tracker URL
No response
Explainer URL
No response
TAG Design Review URL
No response
Mozilla standards-positions issue URL
mozilla/standards-positions#813
WebKit Bugzilla URL
No response
Radar URL
No response
Description
Chromium would like to implement snapshotting of what is now the "fallback base URL" for about:blank and about:srcdoc iframes and popup windows. Furthermore, because a document's "creator" can be different from its navigation "initiator", we've picked the initiator as the document from which an about:srcdoc/about:blank document's base URL is to be inherited, for consistency. We've generally received positive comments about these changes from WebKit folks and many others.
The current fallback base URL mechanism expects to be able to:
- Dynamically access a parent Document's live URL, for
about:srcdociframes - Dynamically access a Document's creator Document's live URL, for
about:blankpopups
Bad side-effects of the current spec
We, and many others involved in discussions over the years, believe this has bad side-effects: - It makes it harder to move things like sandboxed `srcdoc` iframes out-of-process, since one must synchronize the parent/creator's live URL across processes to simulate the current spec - It violates some security and/or privacy expectations of frame sandboxing, which ideally should under no circumstances be able to spy on an embedder frame's live URL - The current spec seems broken in related ways. For example, the creator frame **A** (reached into by the "creator base URL" algorithm) can be gone by the time a frame it creates **B** runs its "fallback base URL", which expects **A** to be around - Being able to observe dynamic updates to another frame's live, potentially out-of-process, URL is tricky & potentially racyMany related spec issues have been filed and discussed over the years, and our proposal can be found in whatwg/html#421 (comment). This is not a formal specification, but I've volunteered to write one in the coming weeks so stay tuned. However we'd love to hear whether WebKit is generally supportive of the direction of snapshotting a base URL. Our specific proposal can be condensed into the following observable effects:
- Inherit Base URL from initiator: Inheriting base URLs from the navigation initiator rather than creator is more consistent with the action of the navigation. One way to observe this change is when a sibling iframe A navigates another sibling iframe B to
about:blank; in our proposal, B inherits A's base URL, instead of "dynamically" pointing to its parent's, which could be different. We'd like to make origin inheritance behave like this, too. - Snapshotting the base URL: The base URL that we inherit per the above, would be snapshotted in the "inheriting" about-schemed document, and would never experience dynamic updates from outside of the document
- Base URL in session history: We propose to save the base URL for about:-schemed documents in session history, alongside the document's origin for these same documents. Like the origin, the base URL would only be used when repopulating about:blank & about:srcdoc documents from session history. This is only observable for back/forward navigations to, or session history restorations of these documents, specifically when their original initiator document is not the parent/creator, or no longer exists.
- Detached documents: The current spec's "fallback base URL" mechanism seems broken for detached about:-schemed iframes, referencing a browsing context that no longer exists. Snapshotting the base URL inherently fixes this issue, by keeping it local to the detached document always, requiring no outside information.
Please see this detailed table of the current cross-browser behavior of what we're changing, and our proposed behavior for each scenario: https://docs.google.com/document/d/1Cy6kuOEuYflHWKK-uQ5bU1x6wEDvyGncgJHChF1PG-U/edit?resourcekey=0-f0zbSZ9mwGyXDSqDCqjicw.
/cc @wjmaclean & @csreis
Activity
annevk commentedon Jun 9, 2023
I agree that this sounds like a solid improvement to a somewhat messy state of affairs. Thank you for working on sorting it out!
I'm curious why you would not want to encourage other browsers to adopt Chromium's behavior around popups. Would that create an inconsistency for policy container?
Regardless, I suggest that we mark this as "position: support" one week from now.
wjmaclean commentedon Jun 15, 2023
Actually we would like to encourage all browsers to adopt the proposed changes around popups. :-)
annevk commentedon Jun 15, 2023
I understand that, I was hoping to learn about the design decision you made.
jyasskin commentedon Jun 15, 2023
From an offline discussion, I think @annevk means to ask why the proposal is to standardize something new instead of standardizing Chromium's current behavior.
wjmaclean commentedon Jun 15, 2023
Ahh, ok, I misundertood. I think the basic idea was that all about:blank frames that have an initiator (be they popups or not) should have a consistent behavior. And using the initiator's base url seems like the right choice, since it comes from the same place that we get the security origin for the frames. Also Chrome's current behavior of just not providing a base url (other than about:blank) for popups is at odds with other browsers.
annevk commentedon Jun 26, 2023
In particular I was thinking that it might be nice to copy less state for popups as Chromium does today, but as we already alias origin it doesn't really matter either way. And HTML hasn't reconciled origin with policy container either so that addresses that question. Not entirely, but sufficiently I think.
Will add the label now per the prior comment.