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 <[email protected]> wrote: > > From: Timmy Willison [mailto:[email protected]] > > Sent: Monday, February 25, 2013 2:55 AM > > > > > On Feb 24, 2013, at 11:18 AM, Glenn Maynard <[email protected]> wrote: > > > > On Sun, Feb 24, 2013 at 8:18 AM, Anne van Kesteren <[email protected]> > 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 > > >
