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 <[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>> 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
