W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2013

Re: [XHR] remove "user cancels request"

From: Julian Aubourg <j@ubourg.net>
Date: Mon, 25 Feb 2013 09:20:58 +0100
Message-ID: <CANUEoeuVqhJTq0Yw8+i30WsJkzW8CiLjFUT_Uz=WRV67g0vnXw@mail.gmail.com>
To: Jungkee Song <jungkee.song@samsung.com>
Cc: Timmy Willison <timmywillisn@gmail.com>, Glenn Maynard <glenn@zewt.org>, Anne van Kesteren <annevk@annevk.nl>, WebApps WG <public-webapps@w3.org>
I have the same questions as Jungkee. What is it you want to remove
exactly? Why do you think the distinction between an user-initiated abort
and a network error is irrelevant? If I am to believe jQuery's bug tracker,
our users want and need the distinction.

On 25 February 2013 07:49, Jungkee Song <jungkee.song@samsung.com> wrote:

> > From: Timmy Willison [mailto:timmywillisn@gmail.com]
> > Sent: Monday, February 25, 2013 2:55 AM
> >
> > > On Feb 24, 2013, at 11:18 AM, Glenn Maynard <glenn@zewt.org> wrote:
> > > > On Sun, Feb 24, 2013 at 8:18 AM, Anne van Kesteren <annevk@annevk.nl>
> wrote:
> > > > Currently the XMLHttpRequest Standard special cases the condition
> > > > where the end user terminates the request. Given that there's less
> and
> > > > less likely to be UI for that kind of feature, does it still make
> > > > sense to expose this distinction from a network error in the API? I
> > > > think we should merge them.
> > > >
> > > > http://xhr.spec.whatwg.org/
> > >
> > > I didn't even know about that behavior.  I've always assumed that the
> only way onabort happens is as a result of my calling abort().  I don't
> think breaking that assumption would break my code, but it's a rare,
> untested code path.  I doubt other developers test it either.  I agree that
> users killing a network request should look like a network error, and in
> general the API should guarantee that onabort is only fired as a result of
> a call to abort().
> > >
>
> According to the current spec, it is already the case that onabort() is
> called only when client.abort() is explicitly called (including CORS
> requests.) onerror() is getting called in actual network errors such as DNS
> error, TLS negotiation failure, cross-origin access violation, etc.
>
> I am not sure what conditions Anne exactly propose to remove from the
> spec. I can think of only three scenarios where the end user *terminates*
> the request: calling open(), calling abort() or explicitly stop in browser
> chrome. I don't think client.open() and explicit browser stop are what Anne
> is talking about.
>
> Anne, could you elaborate what part of the text are you pointing?
>
> If it's the case that you want to merge abort into error, I tend to
> disagree as there can be use cases explicitly putting "cancel" button in UI
> that should be distinguished from network initiated errors.
>
>
> Jungkee
>
> > +1
> >
> >
> >
> > > --
> > > Glenn Maynard
> >
> > - Timmy
>
>
>
Received on Monday, 25 February 2013 08:21:34 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:57 GMT