whatwg/xhr

Aborted flag check in "handle errors"

berniegp opened this issue · 2 comments

It seems that this step in "handle errors" is redundant:

  1. Otherwise, if xhr’s response’s aborted flag is set, run the request error steps for xhr, abort, and "AbortError" DOMException.

A call to abort() unsets the send() flag via the "request error steps". This means that any future execution of "handle errors", before open() is called again, will immediately return:

  1. If xhr’s send() flag is unset, then return.

Step 3 that checks the aborted flag will therefore never run, assuming the only way for the aborted flag to be set is to call abort(), Perhaps there is another way to set the aborted flag of an XMLHttpRequest's response, but I couldn't spot it. Or is this unreachable step a way to future proof "handle errors" ?

It gets set when a fetch is aborted. This can happen through the user pressing Esc, hitting the browser stop button, or the document the fetch is associated with being unloaded, but none of this is well tested and might well go down different code paths.

Thanks for highlighting these (in hindsight) obvious ways of aborting a fetch. I was only thinking about programmatic interventions in javascript.