Cannot differentiate between cancelled XHR and network error

[rbuchholz]

There is currently no way to differentiate between a jQuery XHR that failed because it was cancelled by the browser (e.g. when unloading the page) and one that could not be completed due to a network error (e.g. connection refused).

In both cases, I get the following response object to an error handler:

> response.status
0
> response.statusText
"error"
> response.getAllResponseHeaders()
""

Note that the two cases give identical guarantees on for the server side state (the request may or may not have reached the server). However, they must often be handled differently on the client side: For a failed request, error handling is warranted, possibly resaulting in a retry, an alert box and more. For a cancelled request due to a page refresh, nothing should be handled as it will delay navigation away from the page.

[dmethvin]

What low-level indication do you suggest we use to determine this?

[rbuchholz]

Unfortunately, I have no suggestion for how to determine this. I was hoping for your insights here. According to the ​XMLHttpRequest specification (1 and 2),

4.7.7 Infrastructure for the send() method
[...]
If the end user cancels the request
This is an abort error.

[dmethvin]

I don't believe this is something that can be divined from within the browser. @jaubourg, do you know of a way? If there *is* a way it should be possible to do outside jQuery. Features like navigator.online have similar issues and aren't reliable either, especially in a cross-browser manner.

For now I'll close this as cantfix. If there is some way to do this, it should be possible to prototype outside jQuery to test its cross-browser efficacy.

[jaubourg]

I'm pretty confident those two scenarios cannot be differentiated using native XHR.

What you could try is adding an onunload handler to maintain a flag:

$( window ).unload(function() {
  $.unloading = true;
  setTimeout(function() {
    $.unloading = false;
  }, 100 );
});

It's kinda weak (lots of things can go wrong), but you can test for $.unloading in your handlers and it should be accurate most of the time.

[rbuchholz]

Thank you both for the comments, it seems the standard is either too weak or its implementations are lacking the foresight for this scenario.

Replying to jaubourg:

What you could try is adding an onunload handler to maintain a flag:

Does this work for you? At least in Webkit, the outstanding request is aborted by the browser before window's unload handler is called.

[rbuchholz]

For Mozilla, this is already tracked: ​https://bugzilla.mozilla.org/show_bug.cgi?id=768596

I created a bug for Chromium: ​http://code.google.com/p/chromium/issues/detail?id=162817