Hi all,
I mistakenly landed the
[CL](https://chromium-review.googlesource.com/c/chromium/src/+/6509110)
in M140 before getting the intent to ship approved. My apologies
for that.
I'd appreciate guidance on how to proceed, given that.
One way to go would be to keep the CL landed, and get your
approvals (and the approval of the various checks retroactively).
Another would be to revert the CL and try to merge-back that
revert to 140 (allthough stable cut was yesterday :'( ).
Please let me know which way you prefer to go.
Thanks,
Chris Harrelson schrieb am Mittwoch, 14. Mai 2025 um 17:13:58 UTC+2:
Please also fill out the Privacy, Security, Enterprise,
Debuggability and Testing sections in the chromestatus entry.
On Tue, May 13, 2025 at 9:51 PM Domenic Denicola
<dom...@chromium.org> wrote:
On Wed, May 14, 2025 at 5:10 AM Chromestatus
<ad...@cr-status.appspotmail.com> wrote:
Contact emails
hjanu...@gmail.com
Explainer
None
Specification
https://html.spec.whatwg.org/multipage/links.html#link-type-modulepreload:script-fetch-options
Summary
Fixes modulepreload to properly send referrer headers
by using ClientReferrerString() instead of
NoReferrer(). This aligns Chrome with the HTML
specification which requires using the client's
referrer for module fetches. Includes WPT test
verifying both dynamic imports and modulepreload
correctly send referrer headers.
Can you update this to talk about what effects web
developers see, instead of using the names of
Chromium-codebase functions? This summary will be
reflected to web developer-facing blog posts and such.
Blink component
Blink>Loader>Preload
<https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ELoader%3EPreload%22>
TAG review
None
TAG review status
Not applicable
Risks
Interoperability and Compatibility
The primary risk is that some servers may have
adapted to Chrome's non-standard behavior,
implementing logic that assumes modulepreload
requests will never include referrer headers. These
systems could potentially mishandle or reject
requests with the newly added referrer information.
However, this risk is mitigated by the fact that
other major browsers already implement the correct
behavior, meaning most cross-browser web applications
should already handle referrer headers properly.
Additionally, since modulepreload is a relatively
recent feature, widespread dependence on the
incorrect behavior is unlikely. The benefit of
standards compliance and consistent behavior across
script loading methods outweighs these potential
compatibility concerns.
/Gecko/: Shipped/Shipping
/WebKit/: Shipped/Shipping
/Web developers/: No signals
/Other signals/:
WebView application risks
Does this intent deprecate or change behavior of
existing APIs, such that it has potentially high risk
for Android WebView-based applications?
None
Debuggability
None
Will this feature be supported on all six
Blink platforms (Windows, Mac, Linux,
ChromeOS, Android, and Android WebView)?
No
Is this feature fully tested by
web-platform-tests
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?
No
Above you said there were WPTs, but here you say there
are not. Which is correct? If there are such tests, can
you provide links to them?
Flag name on about://flags
None
Finch feature name
None
Non-finch justification
None
Either a Finch feature name or (rarely) a non-Finch
justification is necessary for any possibly-breaking
change like this.
Rollout plan
Will ship enabled for all users
Requires code in //chrome?
False
Tracking bug
https://crbug.com/409959472
Estimated milestones
No milestones specified
Anticipated spec changes
Open questions about a feature may be a source of
future web compat or interop issues. Please list open
issues (e.g. links to known github issues in the
project for the feature specification) whose
resolution may introduce web compat/interop risk
(e.g., changing to naming or structure of the API in
a non-backward-compatible way).
None
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5144463990849536?gate=4969922291302400
This intent message was generated by Chrome Platform
Status <https://chromestatus.com>.
--
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+...@chromium.org.
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6823a747.050a0220.624fd.01b3.GAE%40google.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6823a747.050a0220.624fd.01b3.GAE%40google.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+...@chromium.org.
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra-BywrbKFHpjkM-SVespzLEesezHZSkn9S_vy1UrWXKjQ%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra-BywrbKFHpjkM-SVespzLEesezHZSkn9S_vy1UrWXKjQ%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 visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b42f99d4-1881-476a-acfc-e98bde8dee54n%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b42f99d4-1881-476a-acfc-e98bde8dee54n%40chromium.org?utm_medium=email&utm_source=footer>.
