- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 21 Sep 2011 14:28:00 -0700
- To: Glenn Maynard <glenn@zewt.org>
- Cc: Eric U <ericu@google.com>, arun@mozilla.com, Kyle Huey <me@kylehuey.com>, public-webapps@w3.org, Anne van Kesteren <annevk@opera.com>
On Wed, Sep 21, 2011 at 11:12 AM, Glenn Maynard <glenn@zewt.org> wrote: > On Tue, Sep 20, 2011 at 8:40 PM, Eric U <ericu@google.com> wrote: >> >> Indeed--however, from a quick skim of XHR and XHR2, that's not what >> they do. They let open() terminate abort(), however far along it's >> gotten. If we did that, then an abort killed by a read might lead to >> the aborted read never getting an onloadend. But you could still get >> the stack-busting chain of onloadstart/onabort. > > Yuck. I agree that's not a good thing to mimic for the sake of > consistency. Anne, is this intentional, or just something XHR is just stuck > with for compatibility? It looks like a new problem in XHR2--this couldn't > happen in XHR1, because there was no abort event fired before loadend. > >> If we wanted to prevent read methods from being called during abort, >> we'd probably want to do that by setting an "aborting" flag or mucking >> around with yet another readyState of ABORTING. > > That's annoying, but it's better than the current situation, and I think > better than the XHR situation. Receiving loadstart should guarantee the > receipt of loadend. > > On Tue, Sep 20, 2011 at 7:43 PM, Jonas Sicking <jonas@sicking.cc> wrote: >> >> 1. onloadstart fires exactly once >> 2. There will be one onprogress event fired when 100% progress is reached >> 3. Exactly one of onabort, onload and onerror fires >> 4. onloadend fires exactly once. >> 6. no onprogress events fire before onloadstart >> 5. no onprogress events fire after onabort/onload/onerror >> 6. no onabort/onoad/onerror events fire after onloadend > > 7. after loadstart is fired, loadstart is not fired again until loadend has > been fired (ie. only one set of progress events can be active on an object > at one time). > > More precisely: loadstart should not be fired again until the dispatch of > loadend *has completed*. That is, you can't start a new progress sequence > from within loadend, either, because there may be other listeners on the > object that havn't yet received the loadend. I don't think we can do that for XHR without breaking backwards compat. / Jonas
Received on Wednesday, 21 September 2011 21:28:57 UTC