- From: Eric U <ericu@google.com>
- Date: Tue, 17 Jan 2012 15:56:12 -0800
- To: Anne van Kesteren <annevk@opera.com>
- Cc: public-webapps@w3.org, Jonas Sicking <jonas@sicking.cc>, Glenn Maynard <glenn@zewt.org>
On Tue, Dec 20, 2011 at 9:24 AM, Anne van Kesteren <annevk@opera.com> wrote: > Sorry for restarting this thread, but it seems we did not reach any > conclusions last time around. > > On Thu, 03 Nov 2011 00:07:48 +0100, Eric U <ericu@google.com> wrote: >> >> I think I may have missed something important. XHR2 specs just this >> behavior w.r.t. abort [another open will stop the abort's loadend] but >> /doesn't/ spec that for error or load. That is, an open() in onerror >> or onload does not appear to cancel the pending loadend. Anne, can >> you comment on why? > > > I think I did not consider that scenario closely enough when I added support > for these progress events. > > open() does terminate both abort() and send() (the way it does so is not > very clear), but maybe it would be clearer if invoking open() set some kind > of flag that is checked by both send() and abort() from the moment they > start dispatching events. > > http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html Ah, I see how that works now. So if you call open from onerror/onabort/onload, there's no loadend from the terminated XHR. And if you call open before onerror/onabort/onload, you don't get any of those either? If you call open from onerror, do other listeners later in the chain get their onerror calls? > Glenn suggested not allowing open() at all, but I think for XMLHttpRequest > we are past that (we have e.g. the readystatechange event which has been > around since XMLHttpRequest support was added and open() is definitely > called from it in the wild). > > > -- > Anne van Kesteren > http://annevankesteren.nl/
Received on Tuesday, 17 January 2012 23:57:00 UTC