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.
On Fri, Jul 7, 2023 at 12:01 PM W. James MacLean <wjmacl...@chromium.org> wrote: > 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. > > On Mon, 3 Jul 2023 at 00:03, Yoav Weiss <yoavwe...@chromium.org> wrote: > >> 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. >> >> On Mon, Jul 3, 2023 at 4:00 AM Domenic Denicola <dome...@chromium.org> >> wrote: >> >>> 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 >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra-2-MP_KecE6rBx5xcJb6QiM0BCpOEEoRdkJ_BxMHWwug%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/CADAYvof1yr%2BJmW0ByoFLzp%2BnK0gQwfOxkEOP4gNbKVHWCik-pw%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADAYvof1yr%2BJmW0ByoFLzp%2BnK0gQwfOxkEOP4gNbKVHWCik-pw%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/CAP-uykD%3DyZ860rRusrecSLGixNfnbkNuyLWU7-8P5WyzfHsePQ%40mail.gmail.com.
