LGTM3 for a careful rollout! On Wed, Jul 12, 2023 at 3:53 PM Daniel Bratell <bratel...@gmail.com> wrote:
> LGTM2 > > /Daniel > On 2023-07-10 21:55, Mike Taylor wrote: > > LGTM1 > On 7/10/23 11:23 AM, Dominic Farolino wrote: > > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAP-uykD%3DyZ860rRusrecSLGixNfnbkNuyLWU7-8P5WyzfHsePQ%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/1d6c8843-c50c-b0e3-edb6-a2027500046d%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1d6c8843-c50c-b0e3-edb6-a2027500046d%40chromium.org?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/CAL5BFfV4TktrK3EzHFAdvF-8w6OMok90xmXBKMb_42Gbgaz3NQ%40mail.gmail.com.
