- From: Adrian Bateman <adrianba@microsoft.com>
- Date: Mon, 18 Apr 2011 19:55:17 +0000
- To: Jonas Sicking <jonas@sicking.cc>
- CC: "arun@mozilla.com" <arun@mozilla.com>, Eric Uhrhane <ericu@google.com>, "Web Applications Working Group WG (public-webapps@w3.org)" <public-webapps@w3.org>, Arun Ranganathan <aranganathan@mozilla.com>
On Monday, April 18, 2011 12:04 PM, Jonas Sicking wrote:
> On Mon, Apr 18, 2011 at 9:02 AM, Adrian Bateman <adrianba@microsoft.com>
> wrote:
> > On Friday, April 15, 2011 2:41 PM, Jonas Sicking wrote:
> >> Yes. I.e. the semantics of readAsX is basically:
> >>
> >> readAsX(...) {
> >> if (requestInProgress)
> >> abort();
> >>
> >> ... start new reading ...
> >> 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.
Currently the spec says "Queue a task to dispatch a progress event called
loadstart". Is that incorrect or just different when restarting a read?
Adrian.
Received on Monday, 18 April 2011 19:55:45 UTC