W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2012

Re: [fileapi] timing of readyState changes vs. events

From: Anne van Kesteren <annevk@opera.com>
Date: Sat, 03 Mar 2012 11:10:08 +0100
To: "Eric U" <ericu@google.com>
Cc: "Arun Ranganathan" <aranganathan@mozilla.com>, "Web Applications Working Group WG" <public-webapps@w3.org>, "Jonas Sicking" <jonas@sicking.cc>
Message-ID: <op.walai6td64w2qv@annevk-macbookpro.local>
On Fri, 02 Mar 2012 23:31:38 +0100, Eric U <ericu@google.com> wrote:
> On Thu, Mar 1, 2012 at 11:09 PM, Anne van Kesteren <annevk@opera.com>  
> wrote:
>> Uhm. What you need to do is queue a task that changes the state and  
>> fires the event. You cannot just fire an event from asynchronous  
>> operations.
> Pardon my ignorance, but why not?  Is it because you have to define
> which task queue gets the operation?

Yeah, otherwise it would be undefined when the operation occurs relative  
to other asynchronous tasks, such as timeouts, events, and fetching.

> So would that mean that e.g. the current spec for readAsDataURL would
> have to queue steps 6 and 8-10?

Yeah. Actually, I think you want to queue a single task when the read is  
completed and then do 7, 8, 6, 9, 10 within that task (in that order, the  
current order seems wrong).

Anne van Kesteren
Received on Saturday, 3 March 2012 10:10:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:31 UTC