- From: Eric Uhrhane <ericu@google.com>
- Date: Fri, 10 Dec 2010 15:30:37 -0800
- To: James Robinson <jamesr@google.com>
- Cc: Anne van Kesteren <annevk@opera.com>, public-webapps@w3.org, Web Applications Working Group Issue Tracker <sysbot+tracker@w3.org>
On Fri, Dec 10, 2010 at 3:17 PM, James Robinson <jamesr@google.com> wrote: > On Fri, Dec 10, 2010 at 2:04 PM, Eric Uhrhane <ericu@google.com> wrote: >> >> On Fri, Dec 10, 2010 at 2:39 AM, Anne van Kesteren <annevk@opera.com> >> wrote: >> > On Fri, 10 Dec 2010 03:24:38 +0100, Web Applications Working Group Issue >> > Tracker <sysbot+tracker@w3.org> wrote: >> >> >> >> ISSUE-173 (ericu): terminal FileWriter progress events should be queued >> >> [File API: Writer] >> >> >> >> http://www.w3.org/2008/webapps/track/issues/173 >> >> >> >> Raised by: Eric Uhrhane >> >> On product: File API: Writer >> >> >> >> When a FileWriter successfully completes a write, currently it: >> >> * dispatches a write event >> >> * sets readyState to DONE >> >> * dispatches a writeend event >> >> >> >> If you want to start a new write, you can't do it in onwrite, since >> >> readyState is still WRITING. Those events should be queued for >> >> asynchronous >> >> delivery, so that readyState is DONE by the time they get handled. If >> >> you >> >> set up a new write in onwrite, you'll still run the risk of getting >> >> confused >> >> by the subsequent writeend from the previous write, but that's >> >> detectable. >> >> >> >> I'll have to look and see what other events should be marked as queued. >> > >> > Why not queue a task that changes readyState and then dispatches write >> > followed by writeend, "synchronously" from the task. That is how a >> > number of >> > things work in XMLHttpRequest. >> >> That would work too. Any reason that you don't want to set readyState >> before queueing the task? This is already happening asynchronously, >> in response to the write finishing--the important thing is just to >> make sure the events are queued, and readyState is updated, before the >> first handler runs. > > I'm not familiar with this particular API, but in general I think it's > important that state variables be set at the same time that the relevant > event fires. In other words, code that polls readyState or similar > attributes should not be able to observe any change before the related event > is fired. Yeah, that makes sense [+thanks to Jonas for pointing this out off-list]. I'll link the readyState change with onwrite in the success case and onerror in the failure case, then have onwriteend come after. > - James >> >> > -- >> > Anne van Kesteren >> > http://annevankesteren.nl/ >> > >> > >> > >
Received on Friday, 10 December 2010 23:31:22 UTC