- From: Eric U <ericu@google.com>
- Date: Tue, 20 Sep 2011 17:40:25 -0700
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Glenn Maynard <glenn@zewt.org>, arun@mozilla.com, Kyle Huey <me@kylehuey.com>, public-webapps@w3.org
On Tue, Sep 20, 2011 at 5:32 PM, Jonas Sicking <jonas@sicking.cc> wrote: > On Tue, Sep 20, 2011 at 5:26 PM, Glenn Maynard <glenn@zewt.org> wrote: >> On Tue, Sep 20, 2011 at 8:01 PM, Eric U <ericu@google.com> wrote: >>> >>> I have a read running, and at some point I abort it--it could be in >>> onprogress or elsewhere. In onabort I start another read. In >>> onloadstart I abort again. Repeat as many times as you like, then let >>> a read complete. I believe we've specced that the event sequence >>> should look like this: >>> >>> loadstart >>> [progress]* >>> ------[events from here to XXX happen synchronously, with no queueing] >>> abort >>> loadstart >>> >>> abort >>> loadstart >> >> XHR handles this by not allowing a new request to be opened until the >> abort() method terminates. Could that be done here? It seems like an >> important thing to be consistent about. >> >> http://dev.w3.org/2006/webapi/XMLHttpRequest/#the-abort-method > > Ooh, that's a good idea. > > / Jonas 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. 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.
Received on Wednesday, 21 September 2011 00:41:06 UTC