W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

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

From: Eric U <ericu@google.com>
Date: Wed, 21 Sep 2011 15:14:29 -0700
Message-ID: <CAHvSExdZEV80tfh0m_65u2DLBjjpAZPTUPavHGhAktuR6Z3Lag@mail.gmail.com>
To: Glenn Maynard <glenn@zewt.org>
Cc: Jonas Sicking <jonas@sicking.cc>, arun@mozilla.com, Kyle Huey <me@kylehuey.com>, public-webapps@w3.org, Anne van Kesteren <annevk@opera.com>
On Wed, Sep 21, 2011 at 3:09 PM, Glenn Maynard <glenn@zewt.org> wrote:
> On Wed, Sep 21, 2011 at 5:44 PM, Eric U <ericu@google.com> wrote:
>>
>> If we want the file specs to match the XHR spec, then we can just
>> leave this as it is in File Reader, and I'll match it in File Writer.
>> Recursion depth limit is up to the UA to set.  But I look forward to
>> hearing what Anne has to say about it before we settle on copying it.
>
> In my opinion, providing the "no nesting" guarantee is more useful than
> being consistent with XHR, if all new APIs provide it.

If we eliminate it entirely, then you can't ever start a new read on
the same object from the abort handler.  That seems like a reasonable
use case.

> This sort of thing seems obviously useful:
>
> function showActivity(obj)
> {
>     obj.addEventHandler("loadstart", function() { div.hidden = false; },
> false);
>     obj.addEventHandler("loadend", function() { div.hidden = true; },
> false);
> }
>
> With the currently specced behavior, this doesn't work--the div would end up
> hidden when it should be shown.  You shouldn't have to care how other code
> is triggering reads to do something this simple.

Adding a number-of-reads-outstanding counter isn't that much more
code.  And if you're really trying to keep things simple, you're not
aborting and then starting another read during the abort, so the above
code works in your app.
Received on Wednesday, 21 September 2011 22:15:10 GMT

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