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 16:28:16 -0700
Message-ID: <CAHvSExcrXPwEdQFmChSvhmWZ=DrV96ESj+y=cB3CFr_WeGFKyQ@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 Tue, Sep 20, 2011 at 3:36 PM, Eric U <ericu@google.com> wrote:
> 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?

On further reflection, another requirement prevents this in some
cases.  If you've made a non-terminal progress event less than 50ms
before completion, you're not permitted to make another at completion,
so I think you'd go straight to load and loadend.  However, if the
entire load took place in a single underlying operation that took less
than 50ms, do you have your choice of whether or not to fire
onprogress once before onload?

> "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.
>
> Thanks,
>
>    Eric
>
Received on Tuesday, 20 September 2011 23:28:57 GMT

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