- From: Eric U <ericu@google.com>
- Date: Tue, 20 Sep 2011 15:36:19 -0700
- To: arun@mozilla.com
- Cc: Kyle Huey <me@kylehuey.com>, Web Applications Working Group WG <public-webapps@w3.org>, Jonas Sicking <jonas@sicking.cc>
On Mon, May 23, 2011 at 6:19 PM, Arun Ranganathan <arun@mozilla.com> wrote: > On 5/23/11 6:14 PM, Arun Ranganathan wrote: > > 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 :) > > Sorry, to be a bit clearer: I'm talking about Eric changing > http://dev.w3.org/2009/dap/file-system/file-writer.html#widl-FileSaver-abort-void > to match http://dev.w3.org/2006/webapi/FileAPI/#dfn-abort > > -- A* > > Sorry about the long delay here--a big release and a new baby absorbed a lot of my time. I'm going through the abort sequence right now, and it turns out that there are a number of places in various algorithms in FileWriter that should match FileReader more closely than they do. However, there a couple of edge cases I'm unsure about. 1) Do you expect there to be an event called progress that indicates a complete read, before the load event? "user agents MUST return at least one such result while processing this read method, with the last returned value at completion of the read" -- Does that mean during onprogress, or would during onloadend be sufficient? What if the whole blob is read in a single backend operation--could there be no calls to onprogress at all? [Side note--the phrasing there is odd. You say that "useragents MUST return", but the app's not required to call for the value, and it can't return it if not asked. Did you want to require the useragent to make at least one onprogress call?] 2) The load and loadend events are queued "When the data from the blob has been completely read into memory". If the user agent fires an onprogress indicating all the data's been loaded, and the app calls abort in that event handler, should those queued events be fired or not? "If there are any tasks from the object's FileReader task source in one of the task queues, then remove those tasks." makes it look like no, but I wanted to make sure. If #1 above is "no" or "not necessarily", then this might not ever come up anyway. Thanks, Eric
Received on Tuesday, 20 September 2011 22:37:01 UTC