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

On Tue, Sep 20, 2011 at 3:36 PM, Eric U <> wrote:
> On Mon, May 23, 2011 at 6:19 PM, Arun Ranganathan <> 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.
>> (
>> 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).
>> 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
>> to match
>> -- 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 UTC