> From: Timmy Willison [mailto:timmywill...@gmail.com] > Sent: Monday, February 25, 2013 2:55 AM > > > On Feb 24, 2013, at 11:18 AM, Glenn Maynard <gl...@zewt.org> wrote: > > > On Sun, Feb 24, 2013 at 8:18 AM, Anne van Kesteren <ann...@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
