768596 - If user pressed the ESC button, XMLHttpRequest fires onerror instead of onabort.

Status: RESOLVED INVALID

(Core :: DOM: Core & HTML, defect)

Description

[CoolCmd]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20100101 Firefox/13.0.1
Build ID: 20120614114901

Steps to reproduce:

Send asynchronous XMLHttpRequest.


Actual results:

If user pressed the ESC button before request complete, XMLHttpRequest calls onerror handler.


Expected results:

XMLHttpRequest must call onabort handler.

Comment 1

[u279076]

Would you be able to provide a testcase which demonstrates this bug?

Comment 2

[Robert Buchholz]

What kind of testcase do you need? Start an XMLHttpRequest with an error and abort handler, make sure that it keeps running long enough (large, slow or long polling) and hit escape. The error handler is called where you would expect the abort handler to be called.

For an occurrence of a downstream bug, see http://bugs.jquery.com/ticket/12964 . From my understanding, a resolution of bug #614304 will probably mitigate this issue as well.

Comment 3

[4esn0k]

similar bug, when user navigates away from page with active XHR;

because of this bug it is hard to tell, if this is an abort, or it is an network error.

Comment 4

[Masatoshi Kimura [:emk]]

Does ESC key still abort XHR?

Comment 5

[Anne (:annevk)]

Since bug 614304 was fixed I suspect not. Should probably clean up the XMLHttpRequest too. Firing abort should prolly only happen if you invoke abort().

Comment 6

[4esn0k]

(In reply to Anne (:annevk) from comment #5)
> Firing abort should prolly only happen if you invoke abort()

WHY?

what if i need to reconnect on network error OR notify the user about it?

Comment 7

[4esn0k]

also, Firefox still fires "error" before page unloading, and there is no way to distinguish that "abort" from a network error.

Comment 8

[4esn0k]

@Anne, 
1) it is not removed fully
2) in Chrome and FF you can stop XHR while page loading OR by using window.stop OR with <a download>, ...

Comment 9

[4esn0k]

http://stackoverflow.com/questions/1370322/jquery-ajax-fires-error-callback-on-window-unload
http://stackoverflow.com/questions/4553124/jquery-ajax-calls-success-handler-when-request-fails-because-of-browser-reload
http://stackoverflow.com/questions/4850605/how-best-to-handle-errors-during-jquery-ajax-calls-caused-by-user-clicking-on-li
http://stackoverflow.com/questions/9397318/detecting-that-a-jquery-ajax-call-failed-because-the-page-is-reloading
http://forum.jquery.com/topic/what-s-the-proper-way-to-deal-with-ajax-error-because-of-page-reload
http://ilikestuffblog.com/2009/11/30/how-to-distinguish-a-user-aborted-ajax-call-from-an-error/

Comment 10

[LOST]

Why this bug still has status Unconfirmed? It always reproes as described, both on frame unload and stopping requests using Esc key.
Wasted 5 hours debugging this on unload in FF, until found this bug report.

Comment 11

[Ryan VanderMeulen [:RyanVM]]

Jonas, any thoughts on this?

Comment 12

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I'm a little confused about what this bug is about now that bug 614304 has been fixed.

Is the remaining problem what event is fired when if the page is closed? I.e. if the tab is navigated to another page, or if the tab is simply closed by the user?

Or is there some way that XHR is still affected by the user pressing the ESC key somehow?

Generally speaking, I leave it to Anne to decide which event should be fired if a network connection is terminated due to the user navigating away to a different page.

Generally we should try to match what other browsers do.

Second to that, it makes sense to me if the "abort" event is exclusively used when the page calls the abort() function. And fire "error" events when a network connection is cut due to the user navigating away from a page. However we should absolutely have some sort of indication on that "error" event that it was due to a user action, rather than due to a generic network problem.

But, again, I'll defer to Anne.

Comment 13

[Anne (:annevk)]

It seems per https://bugs.chromium.org/p/chromium/issues/detail?id=162817 Chrome uses the abort event if you navigate away from a page. I think the specification might require error, although all this is rather vaguely defined still. I suspect that's the issue here.

Comment 14

[CoolCmd]

> However we should absolutely have some sort of indication on that "error" event that it was due to a user action, rather than due to a generic network problem.

yes.
error - request fail, but can be repeat.
abort - never repeat.

Comment 15

[Thomas Wisniewski [:twisniewski]]

For the record, Firefox, Chrome, and Safari all fire error events these days when the user presses ESC, so since we have interop I'm closing this issue as INVALID.