Bug Tracker

#12964 closed bug (cantfix)

Opened November 26, 2012 06:13PM UTC

Closed November 26, 2012 09:42PM UTC

Last modified November 27, 2012 11:02AM UTC

Cannot differentiate between cancelled XHR and network error

Reported by: rbuchholz Owned by: rbuchholz
Priority: undecided Milestone: None
Component: unfiled Version: 1.8.3
Keywords: Cc: jaubourg
Blocked by: Blocking:
Description

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.

Attachments (0)
Change History (6)

Changed November 26, 2012 06:21PM UTC by dmethvin comment:1

owner: → rbuchholz
status: new → pending

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

Changed November 26, 2012 06:50PM UTC by rbuchholz comment:2

status: pending → new

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.

Changed November 26, 2012 09:42PM UTC by dmethvin comment:3

cc: → jaubourg
resolution: → cantfix
status: new → closed

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.

Changed November 27, 2012 12:59AM UTC by jaubourg comment:4

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.

Changed November 27, 2012 09:18AM UTC by rbuchholz comment:5

_comment0: 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 [comment:4 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. → 1354008340630260

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 [comment:4 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.

EDIT: This seems to happen before the request abort:

$(window).bind('beforeunload', function() {
  $.unloading = true;
  ...
});

Changed November 27, 2012 11:02AM UTC by rbuchholz comment:6

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