Understood, thanks for the clarification. On Wed, Aug 19, 2026 at 4:50 PM Daniel Clark <[email protected]> wrote:
> To be clear on what I mean below is that you should enable the feature in > Canary so that it goes through canary/dev/beta first before reaching > stable. So if done now that’d ship to Stable in 154. > > If that still doesn’t leave 4 weeks lead time you can leave that > "Announcement lead time” box unchecked if it hasn’t been unchanged for that > long and still request the Adoption review (after ensuring the other boxes > are completed if they apply). The owners of that gate can comment if they > think it needs more lead time; IMO it will likely be fine. > > *From: *Taylor Brandstetter <[email protected]> > *Date: *Wednesday, August 19, 2026 at 12:37 PM > *To: *Daniel Clark <[email protected]> > *Cc: *blink-dev <[email protected]>; [email protected] < > [email protected]>; Chromestatus <[email protected]>; > Adam Rice <[email protected]> > *Subject: *Re: [blink-dev] Re: Intent to Ship: Fetch API: Forward reason > from AbortController to fetch Response > > You don't often get email from [email protected]. Learn why this is > important <https://aka.ms/LearnAboutSenderIdentification> > > 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/CAK35n0bMvwnkbykO%2BvFEdc9Ke4Uaw2%2B6QmNchpVa8RNyEeoRoQ%40mail.gmail.com.
