- From: Eric Uhrhane <ericu@google.com>
- Date: Fri, 10 Dec 2010 14:04:09 -0800
- To: Anne van Kesteren <annevk@opera.com>
- Cc: public-webapps@w3.org, Web Applications Working Group Issue Tracker <sysbot+tracker@w3.org>
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. > -- > Anne van Kesteren > http://annevankesteren.nl/ > >
Received on Friday, 10 December 2010 22:04:56 UTC