This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 25969 - [XHR] Does "process response body" get processed even if the XHR is abort()-ed in readystatechange?
Summary: [XHR] Does "process response body" get processed even if the XHR is abort()-e...
Status: RESOLVED FIXED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: XHR (show other bugs)
Version: unspecified
Hardware: PC Linux
: P2 normal
Target Milestone: ---
Assignee: Anne
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-06-04 04:27 UTC by Takeshi Yoshino
Modified: 2014-06-25 06:55 UTC (History)
2 users (show)

See Also:

Attachments

Description Takeshi Yoshino 2014-06-04 04:27:25 UTC 
"process response" and "process response body" are separately queued (specified in fetch.spec.whatwg.org). Even if abort() is called in readystatechange handler in "process response", it seems we'll run queued task to run "process response body" and run redundant "Handle errors for response" step and unexpectedly (I believe) run steps 3 and 4. Don't we want to insert state check to "process response body" algorithm to skip them, or cancel tasks queued in the networking task source on termination of fetch?

Or, that "handle the tasks queued" is placed in the step "13. Fetch req ..." implies that termination of fetch also cancels task handling?

Anyway, it's nice to add some text for clarification.
Comment 1 Anne 2014-06-04 10:04:30 UTC 
That's a good point.

I think each of process response, process response body, and process end-of-file need a check at the beginning to terminate their substeps if the send() flag is unset (due to invoking abort() or open()).

And then for synchronous fetches we also set the send() flag as it should not affect them.
Comment 2 Anne 2014-06-20 11:22:56 UTC 
I think this was fixed as part of this commit:

https://github.com/whatwg/xhr/commit/dc42bbd5884f7e9214277079853b387d573aca84

We now explicitly check if response is a network error before we continue.
Comment 3 Anne 2014-06-20 11:23:26 UTC 
Does that make sense?
Comment 4 Takeshi Yoshino 2014-06-24 13:09:56 UTC 
(In reply to Anne from comment #3)
> Does that make sense?

Thanks. Confirmed that now the response update step and progress event firing step are skipped. But it looks "handle errors" is still invoked and calling "request error steps" redundantly.
Comment 5 Anne 2014-06-24 14:18:32 UTC 
https://github.com/whatwg/xhr/commit/2ee64552116bed8e201ed9bbf3f4705562920b2d

Thanks, this is hard :-( I think it is now okay.
Comment 6 Takeshi Yoshino 2014-06-25 06:55:39 UTC 
(In reply to Anne from comment #5)
> https://github.com/whatwg/xhr/commit/2ee64552116bed8e201ed9bbf3f4705562920b2d
> 
> Thanks, this is hard :-( I think it is now okay.

Looks good. Thanks!