Side navigation
#12675 closed bug (notabug)
Opened October 08, 2012 07:02PM UTC
Closed October 15, 2012 03:45PM UTC
Last modified July 01, 2013 05:52PM UTC
User aborted ajax requests should result in jqXHR.statusText == 'abort' not 'error'
| Reported by: | andornaut@gmail.com | 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).
Attachments (0)
Change History (9)
Changed October 08, 2012 07:14PM UTC by comment:1
Changed October 15, 2012 03:45PM UTC by comment:2
| component: | unfiled → ajax |
|---|---|
| priority: | undecided → low |
| resolution: | → notabug |
| status: | new → closed |
The statusText is "error", but the "errorThrown" argument is more specific ("cancelled"). No need to check the response headers.
Changed October 15, 2012 03:46PM UTC by comment:3
sry, not "cancelled", "abort"
Changed October 16, 2012 08:09AM UTC by comment:4
Replying to [comment:3 timmywil]:
sry, not "cancelled", "abort"
In a Chrome 22.0.1229.94 extension I get empty string instead of "abort'.
Changed October 16, 2012 01:37PM UTC by comment:5
That is the same browser I am using. Make sure no browser extensions are interfering.
Changed October 16, 2012 08:43PM UTC by comment:6
Replying to [comment:5 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.
Changed October 16, 2012 10:35PM UTC by comment:7
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.
Changed October 30, 2012 09:46PM UTC by comment:8
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
Changed July 01, 2013 05:52PM UTC by comment:9
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 that the "workaround" is not really useable, because it doesn't distinguish between aborted ajax requests, and those with no server response at all.