Bah, IE9 doesn't have onabort. The only other solution I see is to use .onreadystatechange, but that would change other stuff as well.

Could we just document that IE9 doesn't support this? It would be a shame to let IE9 prevent us from doing the right thing for everyone else.

That's probably better than switching everything back to onreadystatechange. Anyone against this?

Looking at the compat code, I don't think use of onreadystatechange would be that cumbersome.

Afaict, it does require determining success/error manually again, which has historically been cumbersome.

Yea, we end up losing a lot of advantages.

No, we can keep the current structure and only use onreadystatechange for the abort case.

Ah, well I tried that first, but onreadystatechange is called before other handlers, and brings up some IE9 quirks, such as not being to access any properties on a manual, native abort – which makes it difficult to test – and not having a solid way to tell the difference between abort and other errors.

For example, verify readyState === 4 and then delay its body (inside of which is an if ( callback ) guard) by a tick so that it only executes if none of onload/onerror/onabort have.

Ah, a setTimeout could do the trick to allow other callbacks to run first.

@dmethvin @gibson042 This works. Let me know if you have ideas to get it smaller.

Ah, a setTimeout could do the trick to allow other callbacks to run first.

Except for synchronous requests, right?

Except for synchronous requests, right?

Right. That's quite an edge case, tho. IE9, native abort, sync only.