- From: Eric U <ericu@google.com>
- Date: Tue, 20 Sep 2011 17:01:34 -0700
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: arun@mozilla.com, Kyle Huey <me@kylehuey.com>, Web Applications Working Group WG <public-webapps@w3.org>
On Tue, Sep 20, 2011 at 4:43 PM, Jonas Sicking <jonas@sicking.cc> wrote: > On Tue, Sep 20, 2011 at 4:28 PM, Eric U <ericu@google.com> wrote: >> 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? > > This is a spec-bug. We need to make an exception from the 50ms rule > for the last onprogress event. > > From the webpage point of view, the following invariants should hold > for each "load": > > 1. onloadstart fires exactly once > 2. There will be one onprogress event fired when 100% progress is reached > 3. Exactly one of onabort, onload and onerror fires > 4. onloadend fires exactly once. > 6. no onprogress events fire before onloadstart > 5. no onprogress events fire after onabort/onload/onerror > 6. no onabort/onoad/onerror events fire after onloadend > > The reason for 2 is so that the page always renders a "complete" > progress bar if it only does progressbar updates from the onprogress > event. > > Hope that makes sense? It makes sense, and in general I like it. But the sequence can get more complicated [specifically, nested] if you have multiple read calls, which is the kind of annoyance that brought me to send the email. I have a read running, and at some point I abort it--it could be in onprogress or elsewhere. In onabort I start another read. In onloadstart I abort again. Repeat as many times as you like, then let a read complete. I believe we've specced that the event sequence should look like this: loadstart [progress]* ------[events from here to XXX happen synchronously, with no queueing] abort loadstart abort loadstart abort loadstart loadend loadend loadend ------[XXX] [progress]+ load loadend Does that look like what you'd expect? Am I reading it right? Yes, this is a wacky fringe case. But it's certainly reasonable to expect someone to start a new read in onabort, so you have to implement at least enough bookkeeping for that case. And UAs will want to defend against stack overflow, in the event that a bad app sticks in an abort/loadstart loop.
Received on Wednesday, 21 September 2011 00:02:15 UTC