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

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?

/ Jonas

Received on Tuesday, 20 September 2011 23:44:22 UTC