Re: [XHR] remove "user cancels request"

On Mon, Feb 25, 2013 at 3:37 AM, Anne van Kesteren <> wrote:

> Sure, for links (i.e. navigation)... For XMLHttpRequest (fetching)
> however those rarely change as that would make applications very
> confusing to the user. At least, when I still worked at Opera at some
> point the progress bars for fetching after the page had loaded (<body>
> load fired) were disabled as they were just too confusing.

Some data points:

- Firefox already sends onerror if you hit escape while an XHR is in
progress.  The onerror handler can just start another XHR request, and
pressing escape again will once again onerror that new request.
- In WebKit, if the document load is still in progress, escape cancels both
the document load (eg. images) and any running XHRs.  If this happens,
onabort is sent to the request.  However, this only happens during initial
document load; after that, XHR requests can't be cancelled.  The onabort
handler can also start another XHR, and since the document load is no
longer in progress, this one can't be cancelled.
- IE9 doesn't seem to abort XHR at all.

WebKit's behavior doesn't make sense.

Firefox's behavior seems to match what you're suggesting, and it's what I'd
expect.  Since it doesn't expose any code paths that can't happen
otherwise, it should also result in the least chance of bugs.

IE9's behavior of not cancelling XHR on escape at all seems reasonable, too.

For navigation,

- Firefox also fires onerror if you navigate while an XHR is in progress.
- WebKit fires onabort.
- IE9 doesn't seem to cancel XHR on navigation.  (You can get an XHR onload
after the user has already clicked a link, if the new page hasn't already
begun to load.)

If authors really want to be able to distinguish a user cancellation from a
regular network error, let's stick a flag on onerror.  It's much worse to
have to carefully distinguish abort() from a user abort.  They're
completely different things.

Glenn Maynard

Received on Monday, 25 February 2013 14:49:01 UTC