- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 20 Sep 2011 16:35:05 -0700
- To: Eric U <ericu@google.com>
- Cc: arun@mozilla.com, Kyle Huey <me@kylehuey.com>, Web Applications Working Group WG <public-webapps@w3.org>
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? > "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? As I understand it, the model we're moving towards is that we should *always* fire an onprogress event which represents 100% progress. This means that if the whole file can be read in a single backend operation then we'll fire onprogress, onload and onloadend, in that order, in rapid succession. Similarly, if a implementation uses buffers of size 65536 bytes somewhere in the implementation, and thus limits reading operations to that size, and the user reads a file that is 65537 bytes, then we should fire one onprogress event for the 65536 first bytes, one onprogress event for the 65537th byte, one onload event and one onloadend event. Does that answer the question? > 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. If the page calls abort() before the onload event has been fired, then the onload event should not fire, only the onabort and onloadend. / Jonas
Received on Tuesday, 20 September 2011 23:36:04 UTC