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

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

From: Eric U <ericu@google.com>
Date: Thu, 1 Mar 2012 16:01:55 -0800
Message-ID: <CAHvSExeH-8CCWCJ0Vr0bv57sxd3zUnDX1NDOBxMt8TS+M_QK3Q@mail.gmail.com>
To: Arun Ranganathan <aranganathan@mozilla.com>
Cc: Web Applications Working Group WG <public-webapps@w3.org>, Jonas Sicking <jonas@sicking.cc>
On Thu, Mar 1, 2012 at 3:16 PM, Arun Ranganathan
<aranganathan@mozilla.com> wrote:
> Eric,
>
>> In the readAsText in the latest draft [1] I see that readyState gets
>> set to done "When the blob has been read into memory fully".
>> I see that elsewhere in the progress notification description, "When
>> the data from the blob has been completely read into memory, queue a
>> task to fire a progress event called load".  So readyState changes
>> separately from the sending of that progress event, since one is
>> direct and the other queued, and script could observe the state in
>> between.
>>
>> In the discussion at [2] we arranged to avoid that for FileWriter.
>>  We
>> should do the same for FileReader.
>
> OK, so the change is to ensure that these events are fired directly, and not queued, right?  I'll make this change.  This applies to all readAs* methods.

Yup.  It should apply to any event associated with a state change [so
e.g. onload, but not onloadend].
Received on Friday, 2 March 2012 00:02:38 GMT

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