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 < miketa...@chromium.org>: > 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 <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> > . > > -- 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/CAFmjHKSsgH7aJtQShehh0mJt2aOZQVqAgVUWsppz1J174s1Aug%40mail.gmail.com.
