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. On Sat, Jul 1, 2023 at 3:41 AM W. James MacLean <wjmacl...@chromium.org> wrote: > Intent to Ship: Inherit Base URL snapshot for about:blank and > about:srcdoc, with about:blank inheriting from initiator, not parent. > > Contact emails > > wjmacl...@chromium.org > > cr...@chromium.org > > d...@chromium.org > > 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 blink-dev+unsubscr...@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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADAYvoe_DU3j3Viiz1uM2qWjSUOBLEMnorerdHOBAcptOW7kag%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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+unsubscr...@chromium.org. 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.
