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: Fri, 2 Mar 2012 14:31:38 -0800
Message-ID: <CAHvSExei3kMvgcJWQ5aM4nXQZirTmrCtcHhGXeSbuU9sBfFNDw@mail.gmail.com>
To: Anne van Kesteren <annevk@opera.com>
Cc: Arun Ranganathan <aranganathan@mozilla.com>, Web Applications Working Group WG <public-webapps@w3.org>, Jonas Sicking <jonas@sicking.cc>
On Thu, Mar 1, 2012 at 11:09 PM, Anne van Kesteren <annevk@opera.com> wrote:
> On Fri, 02 Mar 2012 01:01:55 +0100, Eric U <ericu@google.com> wrote:
>> On Thu, Mar 1, 2012 at 3:16 PM, Arun Ranganathan
>> <aranganathan@mozilla.com> wrote:
>>> 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].
> 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?
So would that mean that e.g. the current spec for readAsDataURL would
have to queue steps 6 and 8-10?

Anyway, my point was just that load needed to be done synchronously
with the change to readyState, but loadend had no such restriction,
since it wasn't tied to the readyState change.
Received on Friday, 2 March 2012 22:32:21 UTC

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