W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2010

Re: [File API] abort()

From: Arun Ranganathan <aranganathan@mozilla.com>
Date: Mon, 6 Dec 2010 15:34:46 -0800 (PST)
To: Anne van Kesteren <annevk@opera.com>
Cc: WebApps WG <public-webapps@w3.org>
Message-ID: <108990613.498026.1291678486116.JavaMail.root@cm-mail03.mozilla.org>

> 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
> event loop model. Much like e.g. XMLHttpRequest and Web Workers do.

I agree with this.

-- A*
Received on Monday, 6 December 2010 23:35:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:14 UTC