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

On Thu, Mar 1, 2012 at 11:09 PM, Anne van Kesteren <> wrote:
> On Fri, 02 Mar 2012 01:01:55 +0100, Eric U <> wrote:
>> On Thu, Mar 1, 2012 at 3:16 PM, Arun Ranganathan
>> <> 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