Open Bug 1568422 Opened 5 years ago Updated 2 years ago

fetch cannot be aborted by AbortController(AbortSignal)

Categories

(Core :: DOM: Service Workers, defect, P3)

68 Branch
defect

Tracking

()

Tracking Status
firefox75 --- fix-optional

People

(Reporter: 291732447, Unassigned)

References

Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

I use fetch API to GET a chunked resource, and use AbortController(AbortSignal) to abort it. (firefox 68.0.x MacOS High Sierra)

Actual results:

I Received a error ’AbortError: The operation was aborted'. after, I capture the interface, the connection to the server is not disconnected, there is still data transmission.

Expected results:

After abort the fetch , the connection to the server should disconnect.

Component: Untriaged → DOM: Networking
Product: Firefox → Core

Hello reporter,
Is it permanent reproducible?
Do you have a minimum test site for this?

Thanks.

Flags: needinfo?(291732447)

(In reply to Junior [:junior] from comment #1)

Hello reporter,
Is it permanent reproducible?
Do you have a minimum test site for this?

Thanks.

This is a test page:
http://45.78.67.162:8080/test

Thanks.

Flags: needinfo?(291732447)

Hello :baku,
You're the expert of both fetching a stream and AbortController.
Comment 2 has a minimum test site.
Could you please take a look? Thanks.

Flags: needinfo?(amarchesini)

When the AbortController signals the fetch object, we call: AbortStream which called JS::ReadableStreamError()
https://searchfox.org/mozilla-central/rev/38c88cbf4be87dfa0636d15a5d3599a8ea0d1a72/dom/fetch/Fetch.cpp#78

But onErrored(), onClosed() or cancel() are never executed. Because of mInputStream->CloseWithStatus() is never executed. The stacktrace is:

#0 0x00007f05d8a8df94 in non-virtual thunk to mozilla::dom::BodyStream::finalize() () at /home/baku/Sources/m/proxy/build/dist/bin/libxul.so
#1 0x00007f05deec8deb in js::ReadableStreamController::clearUnderlyingSource(JS::Handle<js::ReadableStreamController*>, bool) (controller=..., finalizeSource=true) at /home/baku/Sources/m/proxy/src/js/src/builtin/Stream.h:326
#2 0x00007f05dee8f3a5 in ReadableStreamControllerClearAlgorithms(JS::Handle<js::ReadableStreamController*>) (controller=...) at /home/baku/Sources/m/proxy/src/js/src/builtin/Stream.cpp:2969
#3 0x00007f05dee53c73 in ReadableStreamControllerError(JSContext*, JS::Handle<js::ReadableStreamController*>, JS::Handle<JS::Value>) (cx=0x55b93af3b040, unwrappedController=..., e=...)
at /home/baku/Sources/m/proxy/src/js/src/builtin/Stream.cpp:3139
#4 0x00007f05dee53a28 in JS::ReadableStreamError(JSContext*, JS::Handle<JSObject*>, JS::Handle<JS::Value>) (cx=0x55b93af3b040, streamObj=..., error=...) at /home/baku/Sources/m/proxy/src/js/src/builtin/Stream.cpp:4920
#5 0x00007f05da747d9a in mozilla::dom::(anonymous namespace)::AbortStream(JSContext*, JS::Handle<JSObject*>, mozilla::ErrorResult&) (aCx=0x55b93af3b040, aStream=..., aRv=...)
at /home/baku/Sources/m/proxy/src/dom/fetch/Fetch.cpp:78
#6 0x00007f05da76dfbb in mozilla::dom::FetchBody<mozilla::dom::Response>::Abort() (this=0x55b93b975d40) at /home/baku/Sources/m/proxy/src/dom/fetch/Fetch.cpp:1478

Should we call onErrored() between #3 and #4?
See: https://searchfox.org/mozilla-central/rev/38c88cbf4be87dfa0636d15a5d3599a8ea0d1a72/dom/base/BodyStream.cpp#256

Flags: needinfo?(amarchesini) → needinfo?(jorendorff)

Hello jorendorff,
Has it been solved? Thanks.

Hello,
Has it been solved? or probably when will it be solved? Thanks.

Flags: needinfo?(nhnguyen)

Junior, could you triage this? Thanks!

Flags: needinfo?(nhnguyen) → needinfo?(juhsu)

Hello Reporter,
Chrome reports an exception as well.
Could you check if the connection is disconnected in Chrome?

Flags: needinfo?(juhsu) → needinfo?(291732447)

(In reply to Junior [:junior] from comment #8)

Hello Reporter,
Chrome reports an exception as well.
Could you check if the connection is disconnected in Chrome?

Hello :junior,
Chrome reports an exception and the connection is disconnected, I have captured the network use Wireshark.

Flags: needinfo?(291732447)

Change component based on comment 4.
Set P1 since it needs some attention for breaking spec and web-compat.

Component: DOM: Networking → JavaScript: Standard Library
Priority: -- → P1

I will forward this bug to Waldo, as this deals with JS::ReadableStreamError. Unless Jason has time to investigate as well.

Flags: needinfo?(jwalden)
Priority: P1 → P2
Severity: normal → --
Flags: needinfo?(jorendorff)
Priority: P2 → --
Flags: needinfo?(jwalden)
Severity: -- → S3
Priority: -- → P2

Moving to DOM :: Streams (Better home these days).

Unfortunately, this will need a test case to be re-developed (and ideally we should figure out how to write automated testing for this).

Component: JavaScript: Standard Library → DOM: Streams
Priority: P2 → P3

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.

Status: UNCONFIRMED → NEW
Ever confirmed: true

I confirmed that Safari 15.6.1 disconnects when aborted.

Hi Ryo, do you have a test case that shows different behavior in Firefox and Safari when aborting?

Flags: needinfo?(nwtgck)

(In reply to Tom Schuster [:evilpie] from comment #16)

Hi Ryo, do you have a test case that shows different behavior in Firefox and Safari when aborting?

Hello Tom, I have a code but need to minimize it.

Flags: needinfo?(nwtgck)

You can also upload less-minimized code if that's okay for you.

I minimized!

I uploaded demo videos and the code on https://github.com/nwtgck/public-code/tree/acd0085af9308b3cde9b213fe2f6542bf16bbfb0/fetch-abort-and-http-connection. Service Worker causes this issue.

environment

macOS
Firefox: 104.0.2 (64-bit)
Safari: 15.6.1
Chrome: 105.0.5195.102 (Official Build) (x86_64)

Given the comment about service workers, moving component for re-triage.

Component: DOM: Streams → DOM: Service Workers
You need to log in before you can comment on or make changes to this bug.