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

Re: [File API] abort()

From: Anne van Kesteren <annevk@opera.com>
Date: Mon, 06 Dec 2010 13:13:58 +0100
To: "Arun Ranganathan" <aranganathan@mozilla.com>
Cc: "WebApps WG" <public-webapps@w3.org>
Message-ID: <op.vnaj9jb164w2qv@anne-van-kesterens-macbook-pro.local>
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.

>> 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?

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.

Anne van Kesteren
Received on Monday, 6 December 2010 12:14:36 UTC

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