Request time out and error handling

[berniegp]

I believe the wording of https://xhr.spec.whatwg.org/#handle-errors does not convey the intent properly.

When an asynchronous request times out, this is what happens:

If req’s done flag is unset, then set the timed out flag and terminate fetching.

From my understanding of the fetch spec (https://fetch.spec.whatwg.org/#fetching), this causes these steps to run:

If aborted, then:

1. Let aborted be the termination’s aborted flag. <--- aborted == false
2. If aborted is set, then return an aborted network error.
3. Return a network error. <--- This gets passed to "process response"

process response is then executed which calls Handle errors:

1. If the send() flag is unset, return.
2. If response is a network error, then run the request error steps for event error and exception "NetworkError" DOMException.
3. If the timed out flag is set, then run the request error steps for event timeout and exception "TimeoutError" DOMException.
4. Otherwise, ...

Since the fetch algorithm returned a network error after the termination caused by the time out, it seems to me that a strict reading of this would cause step 2 to be executed instead of step 3. Of course, the wording and the platform tests for time outs suggest that the intent is to run step 3.

Should steps 2 and 3 be inverted?

[annevk]

Yeah, seems like they should. @jakearchibald I guess there's no reason for XHR to look at the aborted flag, right?

[jakearchibald]

Flipping those lines around seems right. #214

[annevk]

Thanks all!