On Mon, Apr 18, 2011 at 9:02 AM, Adrian Bateman <[email protected]> wrote: > On Friday, April 15, 2011 2:41 PM, Jonas Sicking wrote: >> On Fri, Apr 15, 2011 at 12:53 PM, Adrian Bateman <[email protected]> >> wrote: >> > Yes, we could live with it but the semantics are more complex. Is this the >> > same as calling abort() then readAsXXX()? >> >> Yes. I.e. the semantics of readAsX is basically: >> >> readAsX(...) { >> if (requestInProgress) >> abort(); >> >> ... start new reading ... >> } >> >> > When does the abort event get queued? What >> > will be the state of the reader at this point? Will loadend get fired? It >> > needs careful speccing to make sure that the details are handled the same >> > in >> > different implementations. >> >> Calling the abort() fires the "abort" and "loadend" events before the >> function returns. Likewise readAsX fires the "loadstart" event before >> it returns. So if a load has already started, then readAsX fires, >> before it returns, the following events in order: >> >> "abort", "loadend", "loadstart" >> >> But indeed, the spec needs improvements here. > > Does loadstart fire synchronously or asynchronously (presuming the first two > fire > synchronously?)?
All three fire synchronously. I.e. all three events fire before the readAsX function returns. / Jonas
