User aborted ajax requests should result in jqXHR.statusText == 'abort' not 'error'

[andornaut@…]

If a user aborts an ajax request (say, by navigating away), the jqXHR statusText is 'error' when it should be 'abort'.

Chrome Dev Tools reports the status as 'abort', and it would be desirable for jquery to do the same as this would simplify the task of distinguishing user-aborted ajax requests from "real" errors.

One workaround is to check jqXHR.getAllResponseHeaders() as described here: ​http://ilikestuffblog.com/2009/11/30/how-to-distinguish-a-user-aborted-ajax-call-from-an-error/

Note that both jqXHR.statusText and the "textStatus" arg to the error callback should be 'abort'.

This issue probably doesn't cause too many problems in most applications, but I ran into it while developing a Chrome extension, which has transient windows (Browser Action) and longer-living ones (Background Window).

[andornaut@…]

Note that the "workaround" is not really useable, because it doesn't distinguish between aborted ajax requests, and those with no server response at all.

[Timmy Willison]

The statusText is "error", but the "errorThrown" argument is more specific ("cancelled"). No need to check the response headers.

​http://jsbin.com/avalow/1/

[Timmy Willison]

sry, not "cancelled", "abort"

[anonymous]

Replying to timmywil:

sry, not "cancelled", "abort"

In a Chrome 22.0.1229.94 extension I get empty string instead of "abort'.

[Timmy Willison]

That is the same browser I am using. Make sure no browser extensions are interfering.

[mail@…]

Replying to timmywil:

That is the same browser I am using. Make sure no browser extensions are interfering.

I get the same result as anonymous in Chrome 22.0.1229.94.

To be more specific however, a call to "myAJAXvar.abort();" returns your specific "abort" both in the .fail(jqXHR.statusText) and .error(errorThrown).

However upon page navigation to a different URL both return an empty string, thus the same issue as when the ticket was opened.

[anonymous]

OP here

As noted above, this bug occurs when a user navigates (as opposed to an explicit request.abort()).

I caught it while developing a Chrome extension that has a "background page" which sticks around after the aborted navigation occurs.

In my case, the aborted navigation is actually refresh of the chrome extension "browser action popup", but it amounts to the same thing.

[anonymous]

I am seeing the same problem. I cannot distinguish between user abort and loss of network on the ajax call. I get the same thing in chrome 22.0.1229.94 and firefox 16.02. the errorThrown is "" and the statusText is "error" xhr.readyState=0 and xhr.status=0. If I look at the network trace in chrome it has a status text column and I see "cancelled" in the abort case and "failed" in the network failure case but in the $.ajax error function I see no way to access it

[lucas@…]

Hello

Recently I needed to make a queue that is updated via ajax.

It is updated recursively with a interval between each request.

Users complained that they were receiving an error message when accessed any link while the queue is updated.

So I needed to identify if the onError was called by a failure or because the user left navigation during the ajax request.

I fulfilled using the combination of $.ajaxError and $.bind('beforeunload', func) in the following code ​http://jsfiddle.net/7A6Ne/

But I just tested in Chrome 27, IE 10 and Firefox, so I'm afraid because I do not know if implementation of beforeunload is ok in all major browsers.

Should be fine if $.ajaxError tell us if user left navigation.

Duplicated ticket? ​http://bugs.jquery.com/ticket/13171