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
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK35n0bMvwnkbykO%2BvFEdc9Ke4Uaw2%2B6QmNchpVa8RNyEeoRoQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
