- From: Arun Ranganathan <arun@mozilla.com>
- Date: Mon, 18 Apr 2011 18:08:56 -0400
- To: Adrian Bateman <adrianba@microsoft.com>
- CC: Jonas Sicking <jonas@sicking.cc>, Eric Uhrhane <ericu@google.com>, "Web Applications Working Group WG (public-webapps@w3.org)" <public-webapps@w3.org>, Arun Ranganathan <aranganathan@mozilla.com>
On 4/18/11 3:55 PM, Adrian Bateman wrote:
> 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?
Spec. language currently is sub-par, and I'm going to make some changes
to it as soon as I finish the Blob.slice update. Right now, it's
correct w.r.t. starting a read, but incorrect w.r.t. the multiple reads
scenario we've been discussing.
-- A*
Received on Monday, 18 April 2011 22:09:50 UTC