Re: [FileAPI] Updates to FileAPI Editor's Draft

On 6/7/11 1:43 PM, Jian Li wrote:
> I have a couple questions regarding abort behavior.
>
>     * If the reading is completed and the loadend event has been
>       fired, do we want to fire loadend event again when abort()
>       method is called?
>

Right now, if reading is completed (with loadend fired, etc.), abort() 
is specified to *still* fire abort and loadend.  Do you disagree here?
result will be null.

    * Do we want to reset error to null or leave it intact when abort()
      method is called?

The step to fire an error event is eliminated.  Chrome seems to set an 
error to ABORT_ERR which the spec no longer says to do.  I'm inclined to 
leave ABORT_ERR around, but right now, it never really gets used.

-- A*

> Thanks,
>
> Jian
>
> On Wed, May 11, 2011 at 3:49 PM, Arun Ranganathan <arun@mozilla.com 
> <mailto:arun@mozilla.com>> wrote:
>
>     The Editor's Draft of the FileAPI --
>     http://dev.w3.org/2006/webapi/FileAPI/ -- has had some updates.
>      These are the notable changes:
>
>     1. Blob.slice behavior has changed to more closely match
>     String.prototype.slice from ECMAScript (and Array.prototype.slice
>     semantically).  I think we're the first host object to have a
>     slice outside of ECMAScript primitives; some builds of browsers
>     have already vendor-prefixed slice till it becomes more stable
>     (and till the new behavior becomes more diffuse on the web -- Blob
>     will soon be used in the Canvas API, etc.).  I'm optimistic this
>     will happen soon enough.  Thanks to all the browser projects that
>     helped initiate the change -- the consistency is desirable.
>
>     2. The read methods on FileReader raise a new exception --
>     OperationNotAllowedException -- if multiple concurrent reads are
>     invoked.  I talked this over with Jonas; we think that rather than
>     reuse DOMException error codes (like INVALID_STATE_ERR), these
>     kinds of scenarios should throw a distinct exception.  Some things
>     on the web (as in life) are simply not allowed.  It may be useful
>     to reuse this exception in other places.
>
>     3. FileReader.abort( ) behavior has changed.
>
>     4. There is a closer integration with event loops as defined by HTML.
>
>     For browser projects with open bug databases, I'll log some bugs
>     based on test cases I've run on each implementation.  A few
>     discrepancies exist in implementations I've tested; for instance,
>     setting FileReader.result to the empty string vs. setting it to
>     null, and when exceptions are thrown vs. use of the error event.
>
>     Feedback encouraged!  Draft at http://dev.w3.org/2006/webapi/FileAPI/
>
>     -- A*
>
>
>
>