Bug Tracker

Opened 11 years ago

Closed 11 years ago

Last modified 10 years ago

#12675 closed bug (notabug)

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

Reported by: andornaut@… Owned by:
Priority: low Milestone: None
Component: ajax Version: 1.8.0
Keywords: Cc:
Blocked by: Blocking:

Description

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).

Change History (9)

comment:1 Changed 11 years ago by 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.

comment:2 Changed 11 years ago by Timmy Willison

Component: unfiledajax
Priority: undecidedlow
Resolution: notabug
Status: newclosed

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

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

comment:3 Changed 11 years ago by Timmy Willison

sry, not "cancelled", "abort"

comment:4 in reply to:  3 Changed 11 years ago by anonymous

Replying to timmywil:

sry, not "cancelled", "abort"

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

comment:5 Changed 11 years ago by Timmy Willison

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

comment:6 in reply to:  5 Changed 11 years ago by 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.

comment:7 Changed 11 years ago by 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.

comment:8 Changed 11 years ago by 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

comment:9 Changed 10 years ago by 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

Note: See TracTickets for help on using tickets.