Intent to Ship: Inherit Base URL snapshot for about:blank and about:srcdoc, with about:blank inheriting from initiator, not parent.

[W. James MacLean]

Intent to Ship: Inherit Base URL snapshot for about:blank and about:srcdoc, with about:blank inheriting from initiator, not parent.

Contact emails

wjma...@chromium.org

cr...@chromium.org

d...@chromium.org

Explainer

None

Specification

https://github.com/whatwg/html/pull/9464 (original proposal)

Summary

This work aims to fix issues and improve the compatibility of Chromium's implementation of fallback base URL specifically for about:srcdoc and about:blank frames. The base URL can be accessed directly with document.baseURI, and indirectly when resolving relative URLs.  Chromium's current behavior differs from Safari & Firefox in several ways. Chromium and Safari only partially snapshot the base URL for an about:blank/srcdoc document from its creator document, and the about:blank/srcdoc document usually does not observe later changes to its creator document's base URL. Still, such changes may become visible in corner cases (e.g., if the child makes and then reverses changes to its own <base> element, its partial snapshot gets updated from its creator).

 

We propose that the base URL supplied to about:srcdoc and about:blank frames and popups are snapshotted from their initiator at the time the navigation begins. The implementation will also allow base URL to work correctly for about:srcdoc frames when those frames are in a different process from their parent (e.g., sandboxed srcdoc iframes).

Web-Visible Changes in Chrome

• Inherit Base URL from Initiator: We propose to change the spec and implementation to inherit base URLs from the navigation initiator rather than from the frame's creator (where creator is the parent document for about:srcdoc/blank iframes, and the opener for about:blank popups). The creator of a frame may be different from the initiator of a navigation that creates a document, and it is surprising when the origin and base URL are inherited from different incompatible frames.

• Example: Consider the case where a sibling iframe B, with a base url different from its parent A, navigates its sibling iframe to about:blank. Legacy Chrome behavior gives the about:blank iframe its parent A's base url, but its sibling B's origin; our proposal assigns both the origin and base URL from the sibling B (initiator). For srcdoc attribute mutations, both base URL and origin come from the parent as before (unchanged).

• window.open(): At present in Chrome, window.open() and window.open(“about:blank”) lead to a popup frame with document.baseURI = “about:blank”. With the proposed change, the popup frame will inherit the baseURI from the initiator. This brings Chrome into agreement with Safari, and essentially with Firefox (which still sets base URL to “about:blank” for parameter-free calls to window.open()).

• Snapshotting Base URL: We propose to change the spec and implementation such that base URLs should not update in response to parent base URLs changing. The current spec allows such dynamic updates only for about:-schemed Documents, per the fallback base URL mechanism. But these dynamic updates (as opposed to the snapshot we propose) are problematic in that (i) it is difficult to provide if the child frame is cross-process, and (ii) can leak information in cross-origin cases (e.g. the child is sandboxed).

• Chrome currently has a “broken” snapshotting behavior (described above), though in most cases it behaves as a snapshot.

• Safari currently has the same broken snapshotting as Chrome.

• Firefox does not snapshot: it allows a frame to see dynamic changes in its parent.

• Store in Session History: We propose to change the spec and implementation to save the base URL in session history, alongside the document's origin. Like the session history's origin, the base URL would only be used when repopulating about:blank & about:srcdoc documents from session history. This change is only observable for back/forward navigations to, or session history restorations of these about:-schemed documents, specifically when their original initiator document is not the parent, or no longer exists. From manual testing it appears neither Firefox nor Safari currently persist base urls for about:blank in session history.

• Detached Document: Frames that have been removed from their parent, but are still alive and still have their document, will keep their snapshotted base URL in the proposed behavior. The current spec for about:-schemed iframes would have it refer to a non-existent parent in such cases, which so the behavior is ill-defined.

Additional discussion of the underlying issues involved may be found at: 

• https://github.com/whatwg/html/issues/421#issuecomment-1260360824

• https://github.com/whatwg/html/issues/3989

• Design Doc

• https://github.com/whatwg/html/issues/6316

Blink component

Blink>HTML>IFRAME

TAG review

TAG review status

Not applicable

Risks

This change will cause about:blank inherit from the initiator of the navigation, instead of from the parent frame. In many cases these are the same. When they differ, pages may observe the change in behavior. To work around the change, a <base> element can be used to explicitly set the desired base url.

Interoperability and Compatibility

At present Gecko and WebKit differ slightly, and our implementation more closely matches WebKit in that it snapshots the inherited base url at the time of navigation. Our proposed implementation differs from both in that the initiator provides the base url.

Gecko: https://github.com/mozilla/standards-positions/issues/813

WebKit: Support https://github.com/WebKit/standards-positions/issues/197

Web developers: 

Other signals:

WebView application risks

Yes, there is potential for risk here, if apps depend on the previous web visible behavior of base URL inheritance. We will be monitoring the rollout and can disable on Android WebView if any issues arise.

Debuggability

Existing support for observing document.baseURI in DevTools.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes

• html/infrastructure/urls/terminology-0

• html/infrastructure/urls/base-url/

• CL 4652304

Flag name

UI flag: chrome://flags/#enable-new-base-url-inheritance-behavior

Command line flag: --enable-features=NewBaseUrlInheritanceBehavior

Requires code in //chrome?

False

Estimated milestones

M116
(Implementation has been complete for a while now, and will be launching with a field trial first.)

Anticipated spec changes

Beyond our proposal, there was some discussion of future changes to prohibit base URL inheritance for sandboxed about:-schemed documents, but there are compat concerns, so that work is not included here.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5161101671530496

[Domenic Denicola]

Let me just say, with my HTML Standard editor hat on, that I am very excited for these changes. This area is currently a wasteland of non-interoperable behavior, broken specifications, and web-developer-expectations violations. The team has done some amazing work to figure out a model that works well, is conceptually elegant, and has minimal compat concerns. And although I haven't done my editor review yet, I'm excited to see that they've sent spec PRs and a good number of web platform tests for this area.

There may still be compat risks here, but I think the benefits of getting a reasonable model for base URL inheritance are worth pushing forward (with careful deployment and a kill-switch). Thanks so much to the team for this work.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADAYvoe_DU3j3Viiz1uM2qWjSUOBLEMnorerdHOBAcptOW7kag%40mail.gmail.com.

[Yoav Weiss]

A couple of questions:

• Should we wait until the PR matures a bit and gets reviewed? WebKit's position is encouraging, but it'd be an even better signal to be able to land the PR.
• How can we evaluate the compat risk here?

RE the latter, is there a way to usecount how often the baseURI is accessed in places that will change behavior here? That can give us an upper bound on potential breakage.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra-2-MP_KecE6rBx5xcJb6QiM0BCpOEEoRdkJ_BxMHWwug%40mail.gmail.com.

[W. James MacLean]

At present there is no mechanism I'm aware of for tracking when baseURIs are accessed in scenarios where the behavior might be different from what is expected. I'm not quite sure what that would look like exactly, as at the document level we don't expect to know if initiator = parent or not. We expect the compat risk to be quite low, as the initiator != parent case seems likely to be rare. But it might not be zero and we don't have any numbers on what it might actually be.

As Dominic mentioned, we think the risk is low enough that a careful & gradual deployment (with a killswitch available, and an enterprise policy in place to allow disabling the new behavior at the enterprise level) should be safe. But if there's concern that might not be safe enough, we can look into it further. I've held off releasing this to beta for now, though it's been active on canary+dev for quite a while now.

[Dominic Farolino]

The niche-ness of these changes plus the fact that they've been rolled out on Canary+Dev for some time and that we've already smoked out some compat issues at that level of experimentation for the adjacent work the team looked into (censoring the base URL for sandboxed about:srcdoc Documents) makes me fairly comfortable that we have a good grip on the compat implications of this, IMO.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADAYvof1yr%2BJmW0ByoFLzp%2BnK0gQwfOxkEOP4gNbKVHWCik-pw%40mail.gmail.com.

[Mike Taylor]

LGTM1

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAP-uykD%3DyZ860rRusrecSLGixNfnbkNuyLWU7-8P5WyzfHsePQ%40mail.gmail.com.

[Daniel Bratell]

LGTM2

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1d6c8843-c50c-b0e3-edb6-a2027500046d%40chromium.org.

[Yoav Weiss]

LGTM3 for a careful rollout!