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 <mailto:wjmacl...@chromium.org>
cr...@chromium.org <mailto:cr...@chromium.org>
d...@chromium.org <mailto:d...@chromium.org>
Explainer
None
Specification
https://github.com/whatwg/html/pull/9464
<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
partiallysnapshot 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 implementationto inherit base
URLs from the navigation initiatorrather than
from the frame's creator(where creatoris 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.
o
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).
o
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 implementationsuch 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).
o
Chrome currently has a “broken” snapshotting
behavior (described above), though in most
cases it behaves as a snapshot.
o
Safari currently has the same broken
snapshotting as Chrome.
o
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 implementationto 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 onlybe used when repopulating about:blank &
about:srcdoc documents from session history. This
change is only observable for back/forward
navigations to, orsession 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/421#issuecomment-1260360824>
*
https://github.com/whatwg/html/issues/3989
<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
<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
<https://github.com/mozilla/standards-positions/issues/813>
WebKit: Support
https://github.com/WebKit/standards-positions/issues/197
<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
<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>.
