Intent to Ship: Modulepreload Referrer Header Fix
Chromestatus
Contact emails
hjanu...@gmail.comExplainer
NoneSpecification
https://html.spec.whatwg.org/multipage/links.html#link-type-modulepreload:script-fetch-optionsSummary
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.
Blink component
Blink>Loader>PreloadTAG review
NoneTAG review status
Not applicableRisks
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)?
NoIs this feature fully tested by web-platform-tests ?
NoFlag name on about://flags
NoneFinch feature name
NoneNon-finch justification
NoneRollout plan
Will ship enabled for all usersRequires code in //chrome?
FalseTracking bug
https://crbug.com/409959472Estimated 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).
NoneLink to entry on the Chrome Platform Status
https://chromestatus.com/feature/5144463990849536?gate=4969922291302400
Domenic Denicola
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.
Blink component
Blink>Loader>Preload
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 ?
No
Flag name on about://flags
None
Finch feature name
None
Non-finch justification
None
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
--
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 .
Chris Harrelson
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra-BywrbKFHpjkM-SVespzLEesezHZSkn9S_vy1UrWXKjQ%40mail.gmail.com .
Helmut Januschka
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,
Mike Taylor
Hey Helmut,
Oops. It's unfortunate that this feature is missing Privacy, Security, Enterprise, Debuggability & Testing reviews (per Chris' request back in May)... but I think more concerning is the fact that it's not guarded behind a feature flag. If we do end up breaking some sites (the risk seems pretty low, I think... but not zero, and sometimes it takes a few months for subtle bugs to be understood), we don't have an easy way to disable this besides merges and a Stable respin. My instinct would be to revert the CL on trunk and get that merged to 141 Beta ASAP. Adding M140 release owners Srinivas and Krishna for their guidance on what to do for the stable release (maybe nothing is the right answer - it doesn't seem like an emergency right now).
You could then re-land the feature behind a disabled-by-default flag, and work through the normal reviews process.
(There are also unanswered questions from Chris that would help API OWNERs review the feature - can you answer those and kick off the reviews in the chromestatus entry?)
thanks,Mike
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b42f99d4-1881-476a-acfc-e98bde8dee54n%40chromium.org .
Mike Taylor
Thanks Helmet - please don't be too hard on yourself. We've all been there. :)
For now, I would recommend getting the revert landed and requesting a merge into beta. Thanks for requesting the other reviews.
again, super sorry, this might be the single worst chromium day i had since my first contribution.tried to fillout everything in chromestatus entry, and request all the reviews again.a revert CL is here: https://chromium-review.googlesource.com/c/chromium/src/+/6895357 ready to review/submit.just a note, about potential breakage, the WPT's i added, did pass on other browsers already (that should be no excuse; but might be a hint of a hopefully non-nuclear blast radius)please feel free - to let me know what the next steps are, i am fully committed to do whatever is necessary to turn this situation into a positive state.
Krishna Govind
- Is this feature applicable only to Windows? I'm asking because it's listed under the Blink component, but the bug only has OS=Windows applied: [ https://g-issues.chromium.org/issues/409959472 ].
- How safe is it to disable this feature this late in the M140 release cycle?
- The enabled-by-default CL landed on July 12th in Canary 140.0.7309.0, and we branched M140 (7339) on August 4th.
- Do we have any coverage at all with this feature disabled?
- Please provide a launch bug for this feature.
Krishna Govind
Helmut Januschka
Yoav Weiss (@Shopify)
Hi Mike,Thank you for including Srinivas and me in this discussion.Since M140 was released to early stable yesterday with this feature enabled by default and without all necessary approvals, it's critical that we merge the revert to M140 and recut the M140 Stable RC for release on Tuesday, September 2nd.I request that the revert be landed to trunk as soon as possible: [ https://chromium-review.googlesource.com/c/chromium/src/+/6895357 ]I have a few questions for clarity:
- Is this feature applicable only to Windows? I'm asking because it's listed under the Blink component, but the bug only has OS=Windows applied: [ https://g-issues.chromium.org/issues/409959472 ].
- How safe is it to disable this feature this late in the M140 release cycle?
- The enabled-by-default CL landed on July 12th in Canary 140.0.7309.0, and we branched M140 (7339) on August 4th.
- Do we have any coverage at all with this feature disabled?
- Please provide a launch bug for this feature.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMf41adLTqu70hNjXPWUZBEW8QXS53WKAdBH-Wy0G3bh40dBXA%40mail.gmail.com .
Yoav Weiss (@Shopify)
Krishna Govind
Yoav Weiss (@Shopify)
Thank you, any impact on Android Webview? Will it be safe to merge the revert?
Helmut Januschka
Helmut Januschka
Daniel Bratell
Great!
Can you please add the flag to appropriate field in the feature's chromestatus entry so that people can find the flag if needed?
/Daniel
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/189d979c-80c4-46b6-8ac4-74c4453f082en%40chromium.org .
