Re: [XHR] remove "user cancels request"

I agree with Glenn that these user cancellations would be better notified
as errors rather than aborts. Key here is to make it possible for authors
to know what's going on and onabort seems quite confusing.

Side note: IE not cancelling requests is a real pain, we have to abort
manually on unload in jQuery because, in old IEs when using the
ActiveX-based XHRs those pending requests may end up exhausting the pool of
available XHRs!

Le lundi 25 février 2013, Glenn Maynard a écrit :

> On Mon, Feb 25, 2013 at 3:37 AM, Anne van Kesteren <annevk@annevk.nl<javascript:_e({}, 'cvml', 'annevk@annevk.nl');>
> > 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 17:25:21 UTC