W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

Re: [FileAPI] FileReader.abort() and File[Saver|Writer].abort have different behaviors

From: Glenn Maynard <glenn@zewt.org>
Date: Mon, 3 Oct 2011 22:56:06 -0400
Message-ID: <CABirCh90hVx3b5wnpH5SvhZY+wdLqv3PFqsT7mMg8itjUpa94A@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Anne van Kesteren <annevk@opera.com>, arun@mozilla.com, Eric U <ericu@google.com>, Kyle Huey <me@kylehuey.com>, public-webapps@w3.org
On Mon, Oct 3, 2011 at 10:32 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> > (More precisely, no method that starts or finishes a loadstart/loadend
> > sequence can be called from within an algorithm that also starts or
> finishes
> > a sequence.  abort() from within onprogress is fine, for example.)
>
> I think this is a higher cost to developers than the cost of having
> "loadstart" always be paired up with exactly one "loadend".
>

I guess I don't understand the cost here; I've always found moving code to a
timer to be trivial.  The benefits of reducing the number of unobvious event
patterns users have to understand and test seems significant, especially
when you don't control the FileReader itself (eg. you may not be able to say
things like "don't call read() from onerror" if you're just writing the UI).

(I assume you meant "not be paired up with".)

Note that this would mean that you also couldn't start a new load from
> within the "loadend" event since that would cause event listeners
> after yours to receive interleaved loadstart/loadend events.
>

Right.

-- 
Glenn Maynard
Received on Tuesday, 4 October 2011 02:56:33 GMT

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