- From: Julian Aubourg <j@ubourg.net>
- Date: Mon, 25 Feb 2013 09:20:58 +0100
- 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>
- Message-ID: <CANUEoeuVqhJTq0Yw8+i30WsJkzW8CiLjFUT_Uz=WRV67g0vnXw@mail.gmail.com>
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 UTC