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 17:01:34 -0700
Message-ID: <CAHvSExcKx90iRanCyji7tu8Nc5K-jqqtqnap2YswPFq77pqR3A@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: arun@mozilla.com, Kyle Huey <me@kylehuey.com>, Web Applications Working Group WG <public-webapps@w3.org>
On Tue, Sep 20, 2011 at 4:43 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> On Tue, Sep 20, 2011 at 4:28 PM, Eric U <ericu@google.com> wrote:
>> 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?
>
> This is a spec-bug. We need to make an exception from the 50ms rule
> for the last onprogress event.
>
> From the webpage point of view, the following invariants should hold
> for each "load":
>
> 1. onloadstart fires exactly once
> 2. There will be one onprogress event fired when 100% progress is reached
> 3. Exactly one of onabort, onload and onerror fires
> 4. onloadend fires exactly once.
> 6. no onprogress events fire before onloadstart
> 5. no onprogress events fire after onabort/onload/onerror
> 6. no onabort/onoad/onerror events fire after onloadend
>
> The reason for 2 is so that the page always renders a "complete"
> progress bar if it only does progressbar updates from the onprogress
> event.
>
> Hope that makes sense?

It makes sense, and in general I like it.  But the sequence can get
more complicated [specifically, nested] if you have multiple read
calls, which is the kind of annoyance that brought me to send the
email.

I have a read running, and at some point I abort it--it could be in
onprogress or elsewhere.  In onabort I start another read.  In
onloadstart I abort again.  Repeat as many times as you like, then let
a read complete.  I believe we've specced that the event sequence
should look like this:

loadstart
[progress]*
------[events from here to XXX happen synchronously, with no queueing]
abort
loadstart
abort
loadstart
abort
loadstart
loadend
loadend
loadend
------[XXX]
[progress]+
load
loadend

Does that look like what you'd expect?  Am I reading it right?  Yes,
this is a wacky fringe case.  But it's certainly reasonable to expect
someone to start a new read in onabort, so you have to implement at
least enough bookkeeping for that case.  And UAs will want to defend
against stack overflow, in the event that a bad app sticks in an
abort/loadstart loop.
Received on Wednesday, 21 September 2011 00:02:15 GMT

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