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: Tue, 20 Sep 2011 15:36:19 -0700
Message-ID: <CAHvSExebBxC_6njQ+9puyhJdR=j3yuigq=3xhjkyQHZathwC9Q@mail.gmail.com>
To: arun@mozilla.com
Cc: Kyle Huey <me@kylehuey.com>, Web Applications Working Group WG <public-webapps@w3.org>, Jonas Sicking <jonas@sicking.cc>
On Mon, May 23, 2011 at 6:19 PM, Arun Ranganathan <arun@mozilla.com> wrote:
> On 5/23/11 6:14 PM, Arun Ranganathan wrote:
> On 5/23/11 1:20 PM, Kyle Huey wrote:
> To close the loop a bit here, Firefox 6 will make the change to
> FileReader.abort()'s throwing behavior agreed upon here.
> (https://bugzilla.mozilla.org/show_bug.cgi?id=657964)
> We have not changed the timing of the events, which are still dispatched
> synchronously.
> The editor's draft presently does nothing when readyState is EMPTY, but if
> readyState is DONE it is specified to set result to null and fire events
> (but flush any pending tasks that are queued).
> http://dev.w3.org/2006/webapi/FileAPI/#dfn-abort
> Also note that we're NOT firing *both* error and abort; we should only fire
> abort, and *not* error.
> I should change the spec. to throw.  Eric, you might change the spec. (and
> Chrome) to NOT fire error and abort events :)
> Sorry, to be a bit clearer: I'm talking about Eric changing
> http://dev.w3.org/2009/dap/file-system/file-writer.html#widl-FileSaver-abort-void
> to match http://dev.w3.org/2006/webapi/FileAPI/#dfn-abort
> -- A*

Sorry about the long delay here--a big release and a new baby absorbed
a lot of my time.  I'm going through the abort sequence right now, and
it turns out that there are a number of places in various algorithms
in FileWriter that should match FileReader more closely than they do.
However, there a couple of edge cases I'm unsure about.

1) Do you expect there to be an event called progress that indicates a
complete read, before the load event?
"user agents MUST return at least one such result while processing
this read method, with the last returned value at completion of the
read" -- Does that mean during onprogress, or would during onloadend
be sufficient?  What if the whole blob is read in a single backend
operation--could there be no calls to onprogress at all?

[Side note--the phrasing there is odd.  You say that "useragents MUST
return", but the app's not required to call for the value, and it
can't return it if not asked.  Did you want to require the useragent
to make at least one onprogress call?]

2) The load and loadend events are queued "When the data from the blob
has been completely read into memory".  If the user agent fires an
onprogress indicating all the data's been loaded, and the app calls
abort in that event handler, should those queued events be fired or
not?  "If there are any tasks from the object's FileReader task source
in one of the task queues, then remove those tasks." makes it look
like no, but I wanted to make sure.  If #1 above is "no" or "not
necessarily", then this might not ever come up anyway.


Received on Tuesday, 20 September 2011 22:37:01 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:35 UTC