Snapshotting inherited base URL

[domfarolino]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Snapshotting inherited base URL
• Specification or proposal URL (if available): (Specification pending; see below)
• Explainer URL (if available): (See this issue comment and the proposal below)
• Mozillians who can provide input (optional): @smaug----

---

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 received informally positive comments about these changes from WebKit folks and many others, so we are continuing to gather formal opinions here.

The current fallback base URL mechanism expects to be able to:

• Dynamically access a parent Document's live URL, for about:srcdoc iframes
• Dynamically access a Document's creator Document's live URL, for about:blank popups

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 racy

---

Many related spec issues have been filed and discussed over the years, and our proposal can be found in https://github.com/whatwg/html/issues/421#issuecomment-1260360824. 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
• Bbase 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

[zcorpan]

cc @hsivonen

[hsivonen]

I believe this would be consistent with Gecko principal inheritance into about:blank (in the light of new developments at https://bugzilla.mozilla.org/show_bug.cgi?id=1753352 ), so I think a positive position on this makes sense.