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
On 2025-09-02 20:30, Helmut Januschka wrote:
It's relanded now with a feature flag! Thanks to everyone involved,
and sorry for the troubles!
Helmut Januschka schrieb am Dienstag, 2. September 2025 um 11:00:20 UTC+2:
the revert was back-merged into 140, and i am working on a reland
here: http://crrev.com/c/6898599 with feature flag around the change.
[email protected] schrieb am Freitag, 29. August 2025 um
05:40:48 UTC+2:
On Thu, Aug 28, 2025 at 10:25 PM Krishna Govind
<[email protected]> wrote:
Thank you, any impact on Android Webview? Will it be safe
to merge the revert?
Yeah, it will impact Android WebViews as well. (but is safe to
merge)
Merged the revert to latest canary branch 7381 and
triggered a new canary #141.0.7381.3, please verify once
available, will approve M140 merge after canary
coverage/verification.
Updated the bugs:
* https://g-issues.chromium.org/issues/409959472#comment17
* https://g-issues.chromium.org/issues/441770546#comment6
Adding @Daniel Cheng as well for context
Thank you,
Krishna
On Thu, Aug 28, 2025 at 12:46 PM Yoav Weiss (@Shopify)
<[email protected]> wrote:
Merge request issue is at
https://issues.chromium.org/issues/441770546
CL is at
https://chromium-review.googlesource.com/c/chromium/src/+/6897886
On Thu, Aug 28, 2025 at 9:37 PM Yoav Weiss (@Shopify)
<[email protected]> wrote:
On Thu, Aug 28, 2025 at 6:21 PM 'Krishna Govind'
via blink-dev <[email protected]> wrote:
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].
I believe the feature is applicable to all OSes
beyond iOS.
* How safe is it to disable this feature
this late in the M140 release cycle?
o The enabled-by-default CL
<https://chromium-review.googlesource.com/c/chromium/src/+/6509110>
landed on July 12th in Canary
140.0.7309.0, and we branched M140
(7339) on August 4th.
I believe it's safe to disable.
* Do we have any coverage at all with this
feature disabled?
In terms of tests I believe the CL's revert also
removes the relevant WPTs.
* Please provide a launch bug for this feature.
https://issues.chromium.org/issues/409959472
We will need to create an IRM and request a
postmortem for this.
@Srinivas Sista for his input as well.
Thank you,
Krishna
On Thu, Aug 28, 2025 at 8:39 AM Mike Taylor
<[email protected]> wrote:
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.
On 8/28/25 5:36 p.m., Helmut Januschka wrote:
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.
Am Do., 28. Aug. 2025 um 16:54 Uhr
schrieb Mike Taylor <[email protected]>:
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
On 8/27/25 4:11 p.m., Helmut
Januschka wrote:
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
<[email protected]> wrote:
On Wed, May 14, 2025 at
5:10 AM Chromestatus
<[email protected]>
wrote:
Contact emails
[email protected]
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
[email protected].
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
[email protected].
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 [email protected].
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>.
--
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
[email protected].
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMf41adLTqu70hNjXPWUZBEW8QXS53WKAdBH-Wy0G3bh40dBXA%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMf41adLTqu70hNjXPWUZBEW8QXS53WKAdBH-Wy0G3bh40dBXA%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 [email protected].
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/189d979c-80c4-46b6-8ac4-74c4453f082en%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/189d979c-80c4-46b6-8ac4-74c4453f082en%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 [email protected].
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0aba392a-05fc-4a3e-816e-51a3f4d0cc30%40gmail.com.
