Bug Tracker

Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#12964 closed bug (cantfix)

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.

Change History (6)

comment:1 Changed 6 years ago by dmethvin

Owner: set to rbuchholz
Status: newpending

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

comment:2 Changed 6 years ago by rbuchholz

Status: pendingnew

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.

comment:3 Changed 6 years ago by dmethvin

Cc: jaubourg added
Resolution: cantfix
Status: newclosed

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.

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

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

EDIT: This seems to happen before the request abort:

$(window).bind('beforeunload', function() {
  $.unloading = true;
  ...
});
Last edited 6 years ago by rbuchholz (previous) (diff)

comment:6 Changed 6 years ago by rbuchholz

Note: See TracTickets for help on using tickets.