- 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>
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 http://annevankesteren.nl/
Received on Monday, 6 December 2010 12:14:36 UTC