- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 18 Apr 2011 12:03:49 -0700
- To: Adrian Bateman <adrianba@microsoft.com>
- 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 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:
>> On Fri, Apr 15, 2011 at 12:53 PM, Adrian Bateman <adrianba@microsoft.com>
>> 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
Received on Monday, 18 April 2011 19:04:46 UTC