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.

Reply via email to