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

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 :)

-- A*

> - Kyle
>
> On Tue, May 17, 2011 at 3:01 PM, Kyle Huey <me@kylehuey.com 
> <mailto:me@kylehuey.com>> wrote:
>
>     There is actually another difference, the writing API sets the
>     error, readystate value, and dispatches events off of a queued
>     task, while the reading API does that synchronously.
>
>     I'm inclined to think the synchronous version is the way to go
>     here, since then the FileReader or FileWriter is totally ready for
>     another use once the abort method returns.  This is less
>     interesting for FileSaver since that can only do one thing.
>
>     - Kyle
>
>     On Tue, May 17, 2011 at 2:35 PM, Kyle Huey <me@kylehuey.com
>     <mailto:me@kylehuey.com>> wrote:
>
>         The abort behaviors of FileReader and File[Saver|Writer]
>         differ.  The writing objects throw if the abort method is
>         called when a write is not currently under way, while the
>         reading object does not throw.
>
>         The behaviors should be consistent.  I don't particularly care
>         either way, but I believe Jonas would like to change
>         FileReader to match File[Saver|Writer].
>
>         - Kyle
>
>
>