On Tue, Sep 20, 2011 at 5:32 PM, Jonas Sicking <[email protected]> wrote: > On Tue, Sep 20, 2011 at 5:26 PM, Glenn Maynard <[email protected]> wrote: >> On Tue, Sep 20, 2011 at 8:01 PM, Eric U <[email protected]> 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.
