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
http://annevankesteren.nl/
Received on Saturday, 3 March 2012 10:10:43 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:50 GMT