Intent to Ship: Inherit Base URL snapshot for about:blank and about:srcdoc, with about:blank inheriting from initiator, not parent.
Contact emails [email protected] [email protected] [email protected] Explainer None Specification https://github.com/whatwg/html/pull/9464 (original proposal <https://github.com/whatwg/html/issues/421#issuecomment-1260360824>) Summary This work aims to fix issues and improve the compatibility of Chromium's implementation of fallback base URL <https://html.spec.whatwg.org/C#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 <https://html.spec.whatwg.org/C#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 <https://html.spec.whatwg.org/C#document-state-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/421#issuecomment-1260360824 - https://github.com/whatwg/html/issues/3989 - Design Doc <https://docs.google.com/document/d/1e7T1YR5aGDg-eGHKDNnKUWcz1Dr38t_O0-XJqsMeZcE/edit?usp=sharing&resourcekey=0-qCAYJPulnTdo9hV_dPCdhw> - https://github.com/whatwg/html/issues/6316 Blink component Blink> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EJavaScript%3EWebAssembly> 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 <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> ? Yes - html/infrastructure/urls/terminology-0 <https://github.com/web-platform-tests/wpt/tree/master/html/infrastructure/urls/terminology-0> - html/infrastructure/urls/base-url/ <https://github.com/web-platform-tests/wpt/tree/master/html/infrastructure/urls/base-url/> - CL 4652304 <https://chromium-review.googlesource.com/c/chromium/src/+/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 <https://github.com/whatwg/html/issues/8105> some discussion <https://github.com/whatwg/html/issues/9025> of future changes to prohibit base URL inheritance for sandboxed about:-schemed documents, but there are <https://github.com/whatwg/html/issues/8105#issuecomment-1183642551> compat concerns <https://github.com/whatwg/html/issues/9025#issuecomment-1498239984>, so that work is not included here. Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5161101671530496 -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADAYvoe_DU3j3Viiz1uM2qWjSUOBLEMnorerdHOBAcptOW7kag%40mail.gmail.com.
