> > The Adoption gate should be filled out before shipping...where did you see > a reference to "stable for four weeks"?
One of the checkboxes is "*Announcement lead **time*. This feature's name, summary, and milestones have been unchanged for the past four weeks". Which I assumed didn't apply since I changed the milestone (153->154). However, if we ship it by enabling the feature flag on stable immediately—rather than going through canary/dev/beta first—it could actually ship in 153, as the code is ready. Shall I revert that change and proceed with the Adoption prepare to ship? The feature entry hasn't even existed for four weeks, though, is that a problem? On Wed, Aug 19, 2026 at 8:12 AM 'Dan Clark' via blink-dev < [email protected]> wrote: > LGTM2, thanks for helping us consider the compat risks here. My > recommendation to ship "normally" is to just set the feature flag to > "stable" in main and let the change roll out through the normal release > channels. Keep an eye out for bugs, and if there is some problem, that's > when you'd use Finch to set the flag back off in the stable channel. As a > non-Googler I can't speak to the process details of that, but hopefully a > Googler can help if that does become needed. > > On Tuesday, August 18, 2026 at 2:26:34 PM UTC-7 Taylor Brandstetter wrote: > >> > We shouldn’t [ship normally] without trying to understand the risk, >> though. What do you expect potential compatibility issues to look like for >> this? Do developers often have logic branching on specific abort values for >> these promises versus just logging them? Do we have Use Counters that could >> put a high bar on the risk, like a counter for how often already-completed >> fetches are aborted with a reason, or how often the Response methods are >> called for a fetch in this state? >> >> I don't see any use counters specifically for providing an abort reason, >> no. Branching logic on the error from the promises would be the risk, >> although there's a good chance that we were just being overly cautious. I >> have no reason to believe this would be particularly common. If others are >> ok with it, I would suggest just shipping normally with 154. You mentioned >> being ready to roll back via finch; does that mean we would keep the change >> gated behind a flag, but roll it out to 100% immediately for 154 when it >> branches? I'm not very familiar with finch (or this process) so bear with >> me. >> >> I requested the WebKit signal ( >> https://github.com/WebKit/standards-positions/issues/711) and the other >> Prepare to Ship reviews, which I assume should be fairly trivial. I haven't >> requested Prepare to Ship for Adoption yet as it requires the feature to be >> stable for four weeks, and I just changed the milestone to 154. >> >> On Monday, August 17, 2026 at 11:44:29 AM UTC-7 Alex Russell wrote: >> >>> Hey Taylor, >>> >>> I'm going to LGTM1 this on the basis that we do not have compatible >>> behaviour between WebKit/Chromium and Gecko at the moment, reducing the >>> likely risk of breakage. That said, we do need the other review bits filled >>> in (via chromestatus), and my LGTM is contingent on those, as well as >>> requests for positions to Mozilla and WebKit. >>> >>> Best, >>> >>> Alex >>> >>> >>> On Monday, August 17, 2026 at 8:45:19 AM UTC-7 Taylor Brandstetter wrote: >>> >>>> > Can you please give a more specific link into the part of the spec >>>> that defines this behavior? >>>> >>>> Sure thing; the body methods point to the steps for consuming a body: >>>> https://fetch.spec.whatwg.org/#concept-body-consume-body >>>> >>>> Which point to the steps for fully reading a body: >>>> https://fetch.spec.whatwg.org/#body-fully-read >>>> >>>> Which say to read all the bytes from the reader. >>>> >>>> And regarding the reader, the main abort steps ( >>>> https://fetch.spec.whatwg.org/#http-network-fetch) say: >>>> >>>> 1. >>>> >>>> If fetchParams is aborted >>>> <https://fetch.spec.whatwg.org/#fetch-params-aborted>, then: >>>> 1. >>>> >>>> Set response’s aborted flag >>>> <https://fetch.spec.whatwg.org/#concept-response-aborted>. >>>> 2. >>>> >>>> If stream is readable >>>> <https://streams.spec.whatwg.org/#readablestream-readable>, then >>>> error <https://streams.spec.whatwg.org/#readablestream-error> >>>> stream with the result of deserialize a serialized abort reason >>>> >>>> <https://fetch.spec.whatwg.org/#deserialize-a-serialized-abort-reason> >>>> given fetchParams’s controller >>>> <https://fetch.spec.whatwg.org/#fetch-params-controller>’s serialized >>>> abort reason >>>> >>>> <https://fetch.spec.whatwg.org/#fetch-controller-serialized-abort-reason> >>>> and >>>> an implementation-defined >>>> <https://infra.spec.whatwg.org/#implementation-defined> realm >>>> <https://tc39.es/ecma262/#realm>. >>>> >>>> So, both the readable stream and all the body methods consuming it >>>> should be errored with the abort reason. >>>> >>>> > Can you request a WebKit signal? >>>> >>>> I didn't realize it was necessary just for filling a gap in the >>>> implementation, but the wide review documentation >>>> <https://www.chromium.org/blink/launching-features/wide-review/> does >>>> call this case out, so I will request a signal and update the feature >>>> later. >>>> >>>> > I'm still unclear on which tests cover this change. >>>> >>>> I called them out there; "response.X() rejects with abort reason if >>>> already aborted" (for each body method) and "Stream errors once aborted >>>> with abort reason". They fail on everything but Firefox (well except for >>>> the latter which doesn't run on Firefox); I'm assuming the dashboard wasn't >>>> updated when you responded but you can see the failures now. >>>> > Can you say more about this roll out plan? This doesn't seem like the >>>> kind of thing that would need to be rolled out gradually via experiment. >>>> >>>> @ricea had suggested using an experiment, I assume because the use of >>>> fetch is so widespread and changing the type of error that's thrown could >>>> have consequences, even if it's the intended behavior. But I'll let him >>>> comment on that himself if he has anything to add. >>>> > Lastly please request the other "Prepare to Ship" reviews in the >>>> chromestatus entry (Privacy, WP Security, etc). >>>> >>>> Will do. Thanks for your review, Dan. >>>> On Monday, August 10, 2026 at 12:11:55 PM UTC-7 Dan Clark wrote: >>>> >>>>> *> Specification* >>>>> *> https://fetch.spec.whatwg.org <https://fetch.spec.whatwg.org/>* >>>>> >>>>> Can you please give a more specific link into the part of the spec >>>>> that defines this behavior? >>>>> >>>>> *> WebKit: No signal* >>>>> >>>>> Can you request a WebKit signal? >>>>> >>>>> *> Is this feature fully tested by web-platform-tests >>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* >>>>> >>>>> *> Yes> https://wpt.fyi/results/fetch/api/abort/general.any.html >>>>> <https://wpt.fyi/results/fetch/api/abort/general.any.html> Specifically >>>>> the >>>>> tests: * response.arrayBuffer() rejects with abort reason if already >>>>> aborted (and other response methods such as body()) * Stream errors once >>>>> aborted with abort reason. Underlying connection closed.* >>>>> >>>>> I'm still unclear on which tests cover this change. Looking at the test >>>>> results >>>>> <https://wpt.fyi/results/fetch/api/abort/general.any.html?label=master&product=chrome%5Bstable%5D&product=edge%5Bexperimental%5D&product=firefox%5Bexperimental%5D&product=safari%5Bexperimental%5D&aligned> >>>>> all >>>>> are already passing in Chrome Stable except for "Readable stream >>>>> synchronously cancels with AbortError if aborted before reading" which >>>>> doesn't seem to match this scenario. >>>>> >>>>> *> Rollout plan* >>>>> *> (RARE) Experiment users ramp up over time* >>>>> >>>>> Can you say more about this roll out plan? This doesn't seem like the >>>>> kind of thing that would need to be rolled out gradually via experiment. >>>>> >>>>> Lastly please request the other "Prepare to Ship" reviews in the >>>>> chromestatus entry (Privacy, WP Security, etc). >>>>> >>>>> Thanks, >>>>> Dan >>>>> >>>>> On Wednesday, August 5, 2026 at 1:46:36 PM UTC-7 Chromestatus wrote: >>>>> >>>>>> *Contact emails* >>>>>> [email protected] >>>>>> >>>>>> *Specification* >>>>>> https://fetch.spec.whatwg.org >>>>>> >>>>>> *Summary* >>>>>> An AbortController can be passed into fetch to allow a request to be >>>>>> aborted; this is already supported see >>>>>> https://chromestatus.com/feature/5631483679080448 When calling >>>>>> abort, you can optionally pass in an "abort reason", and the original >>>>>> fetch >>>>>> promise if it hasn't resolved should be rejected with that reason. This >>>>>> is >>>>>> already working as intended. *However*, if the fetch promise *has* >>>>>> resolved >>>>>> (after reading the header), but the body has not yet been fully read, >>>>>> this >>>>>> is also intended to propagate the abort reason to the Response methods >>>>>> such >>>>>> as Response.blob(), as well as the ReadableStream Response.body. This >>>>>> part >>>>>> is not currently working; the relevant Promises instead are rejected with >>>>>> generic AbortErrors. Firefox at least is compliant here but >>>>>> chromium/Edge/Safari are not. >>>>>> >>>>>> *Blink component* >>>>>> Blink>Network>FetchAPI >>>>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ENetwork%3EFetchAPI%22> >>>>>> >>>>>> *Web Feature ID* >>>>>> abortable-fetch <https://webstatus.dev/features/abortable-fetch> >>>>>> >>>>>> *Motivation* >>>>>> *No information provided* >>>>>> >>>>>> *Initial public proposal* >>>>>> *No information provided* >>>>>> >>>>>> *TAG review* >>>>>> *No information provided* >>>>>> >>>>>> *TAG review status* >>>>>> Not applicable >>>>>> >>>>>> *Goals for experimentation* >>>>>> None >>>>>> >>>>>> *Risks* >>>>>> >>>>>> >>>>>> *Interoperability and Compatibility* >>>>>> *No information provided* >>>>>> >>>>>> *Gecko*: Shipped/Shipping >>>>>> >>>>>> *WebKit*: No signal >>>>>> >>>>>> *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? >>>>>> *No information provided* >>>>>> >>>>>> >>>>>> *Debuggability* >>>>>> *No information provided* >>>>>> >>>>>> *Will this feature be supported on all six Blink platforms (Windows, >>>>>> Mac, Linux, ChromeOS, 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 >>>>>> https://wpt.fyi/results/fetch/api/abort/general.any.html >>>>>> Specifically the tests: * response.arrayBuffer() rejects with abort >>>>>> reason >>>>>> if already aborted (and other response methods such as body()) * Stream >>>>>> errors once aborted with abort reason. Underlying connection closed. >>>>>> >>>>>> *Flag name on about://flags* >>>>>> *No information provided* >>>>>> >>>>>> *Finch feature name* >>>>>> ForwardReasonToFetchBodyAbort >>>>>> >>>>>> *Rollout plan* >>>>>> (RARE) Experiment users ramp up over time >>>>>> >>>>>> *Requires code in //chrome?* >>>>>> False >>>>>> >>>>>> *Tracking bug* >>>>>> https://issues.chromium.org/issues/502133195 >>>>>> >>>>>> *Estimated milestones* >>>>>> Shipping on desktop 153 >>>>>> Shipping on Android 153 >>>>>> Shipping on WebView 153 >>>>>> Shipping on iOS 153 >>>>>> >>>>>> *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). >>>>>> *No information provided* >>>>>> >>>>>> *Link to entry on the Chrome Platform Status* >>>>>> >>>>>> https://chromestatus.com/feature/5158507786665984?gate=6176253840326656 >>>>>> >>>>>> This intent message was generated by Chrome Platform Status >>>>>> <https://chromestatus.com>. >>>>>> >>>>> -- > You received this message because you are subscribed to a topic in the > Google Groups "blink-dev" group. > To unsubscribe from this topic, visit > https://groups.google.com/a/chromium.org/d/topic/blink-dev/GrS94YdOTJI/unsubscribe > . > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7cbe2d67-6dcf-4115-a456-22eebf737674n%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7cbe2d67-6dcf-4115-a456-22eebf737674n%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/CAK35n0aCCUfo3Jwu%2B-kb11Y2QT-2ztR9O6-S7ui80GSBdaqJkQ%40mail.gmail.com.
