Re: [File API] abort()

Anne,

> On Fri, 03 Dec 2010 16:43:00 +0100, Arun Ranganathan
> <aranganathan@mozilla.com> wrote:
> > ----- Original Message -----
> >> Per http://dev.w3.org/2006/webapi/FileAPI/#abort invoking abort()
> >> always
> >> results in events getting dispatched. This is not what happens in
> >> e.g.
> >> Gecko at the moment. When the state is EMPTY the method simply
> >> returns.
> >
> > To be clear, what is the behavior you are prescribing? Chrome folks,
> > what is the desired behavior for your implementation?
> 
> That when the state of the object is EMPTY the abort() method returns
> directly rather than dispatching a bunch of events as per the current
> specification. There are actually tests in the Mozilla repository that
> contradict the current specification.


I spoke to Jonas, and we're definitely correcting this.  I think that:

1. When the state is NOT EMPTY, we shouldn't fire error but other steps are probably ok.
2. When the state is EMPTY, we should behave as you prescribe.

> 
> 
> >> The dispatching of events should probably also be defined in terms
> >> of
> >> the event queue so it becomes more clear which are to be dispatched
> >> synchronously, etc. Currently all those interactions are quite
> >> vague
> >> in the File API specification.
> >
> > OK, I agree that this could be better, and should be improved in a
> > subsequent version (especially making clear synchronous dispatch).
> > If
> > you could be more specific about your nits, that would help as well.
> 
> What do you mean with subsequent version?

Sorry to be unclear: I only meant the editor's draft, which currently matches the TR, but will change based on feedback we've received after the TPAC.

> 
> What I am basically saying is that for the events that are clearly not
> dispatched synchronously (e.g. reading from a Blob is an asynchronous
> operation) the specification ought to define this in terms of the
> HTML5
> event loop model. Much like e.g. XMLHttpRequest and Web Workers do.


I agree with this.

-- A*