Intent to ship: Abort API

[Andrea Marchesini]

Standards: https://dom.spec.whatwg.org/#aborting-ongoing-activities
https://github.com/whatwg/fetch/pull/523

Summary: In bug 1378342 I have been working on Abort API and its
integration with Fetch API.
There are 2 separate prefs: dom.abortController.enabled and
dom.abortController.fetch.enabled both set to false in release, and to true
in nightly. These allow the enabling of Abort API independently, and the
enabling of Abort + Fetch.
Abort API is a simple API that can be used separately, but when integrated
with Fetch, if a fetch() operation is aborted, this involves the canceling
of the networking, and the body consuming, and the ReadableStream (if
involved and enabled).

Abort API is already part of the DOM spec and I would like to enable it by
default everywhere in our codebase (dom.abortController.enabled). Abort +
Fetch integration is not part of the spec yet. There is a read-ish
pull-request, but as soon as it is merged, I would like to enable the
second pref as well (dom.abortController.fetch.enabled).

Bugs: https://bugzilla.mozilla.org/show_bug.cgi?id=1394085
https://bugzilla.mozilla.org/show_bug.cgi?id=1378342

Other vendors:
Chromium https://bugs.chromium.org/p/chromium/issues/detail?id=750599
I haven't found anything about Edge and Safari.

Estimated target date: Firefox 58.

[Ben Kelly]

On Tue, Aug 29, 2017 at 2:05 AM, Andrea Marchesini <amarc...@mozilla.com>
wrote:

> Abort API is already part of the DOM spec and I would like to enable it by
> default everywhere in our codebase (dom.abortController.enabled). Abort +
> Fetch integration is not part of the spec yet. There is a read-ish
> pull-request, but as soon as it is merged, I would like to enable the
> second pref as well (dom.abortController.fetch.enabled).
>

I don't understand why we would potentially ship these separately. AFAICT
the abort API is only really useful if its integrated into something like
fetch(). Currently the Fetch API is the only part of the platform that
uses it.

Also, we have seen people do thing like feature detect for ReadableStream
and assume Response.body can be a ReadableStream. This is why we are not
shipping the js ReadableStream until the fetch body stream can ship as
well. I worry that people would do a similar kind of feature detection
with Abort API.

Also, while the fetch+abort spec change has not landed yet, we pretty much
have consensus. There are WPT tests in the tree already. I don't think
this is what is blocking shipping the fetch+abort code. To me its a bigger
issue that we still don't pass many of those WPT tests. If we passed the
tests then I think we could reasonably ship it given the current level of
consensus on the spec.

> Other vendors:
> Chromium https://bugs.chromium.org/p/chromium/issues/detail?id=750599
> I haven't found anything about Edge and Safari.
>

Edge has marked their issue for this "fixed":

https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/13009916/

It hasn't shipped yet, of course.

> Estimated target date: Firefox 58.
>

If you are asking to enable the Abort API by default now, wouldn't that put
it in FF57?

[Ben Kelly]

On Tue, Aug 29, 2017 at 9:39 AM, Ben Kelly <bke...@mozilla.com> wrote:

> On Tue, Aug 29, 2017 at 2:05 AM, Andrea Marchesini <
> amarc...@mozilla.com> wrote:
>
>> Abort API is already part of the DOM spec and I would like to enable it by
>> default everywhere in our codebase (dom.abortController.enabled). Abort +
>> Fetch integration is not part of the spec yet. There is a read-ish
>> pull-request, but as soon as it is merged, I would like to enable the
>> second pref as well (dom.abortController.fetch.enabled).
>>
>
> I don't understand why we would potentially ship these separately. AFAICT
> the abort API is only really useful if its integrated into something like
> fetch(). Currently the Fetch API is the only part of the platform that
> uses it.
>
> Also, we have seen people do thing like feature detect for ReadableStream
> and assume Response.body can be a ReadableStream. This is why we are not
> shipping the js ReadableStream until the fetch body stream can ship as
> well. I worry that people would do a similar kind of feature detection
> with Abort API.
>
> Also, while the fetch+abort spec change has not landed yet, we pretty much
> have consensus. There are WPT tests in the tree already. I don't think
> this is what is blocking shipping the fetch+abort code. To me its a bigger
> issue that we still don't pass many of those WPT tests. If we passed the
> tests then I think we could reasonably ship it given the current level of
> consensus on the spec.
>

I spoke with Andrea and Jake (the spec author on this feature) a bit this
morning. Our current test failures are all reasonable for different
reasons:

https://bugzilla.mozilla.org/show_bug.cgi?id=1394085#c4

So I would just like to see bug 1394102 land before we let abortable fetch
ride the trains.

[Andrea Marchesini]

I spoke with Ben yesterday and today and we decided that bug 1394102 should
not block the shipping of this feature. That bug will be fixed as part of
the Service Worker refactoring.
Abort API and the Fetch() integration should be enabled by default in the
next nightly.

[Ben Kelly]

On Wed, Sep 6, 2017 at 12:27 PM, Andrea Marchesini <amarc...@mozilla.com>
wrote:

> Abort API and the Fetch() integration should be enabled by default in the
> next nightly.
>

To clarify, its already enabled in nightly, but the patch to let it ride
the trains is now in inbound.

Thanks for implementing this Andrea!

Ben