- From: Eric U <ericu@google.com>
- Date: Tue, 20 Sep 2011 16:28:16 -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 Tue, Sep 20, 2011 at 3:36 PM, Eric U <ericu@google.com> wrote: > 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? On further reflection, another requirement prevents this in some cases. If you've made a non-terminal progress event less than 50ms before completion, you're not permitted to make another at completion, so I think you'd go straight to load and loadend. However, if the entire load took place in a single underlying operation that took less than 50ms, do you have your choice of whether or not to fire onprogress once before onload? > "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 23:28:57 UTC