W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

Re: [FileAPI] FileReader.abort() and File[Saver|Writer].abort have different behaviors

From: Anne van Kesteren <annevk@opera.com>
Date: Fri, 30 Sep 2011 17:14:37 +0200
To: arun@mozilla.com, "Eric U" <ericu@google.com>
Cc: "Glenn Maynard" <glenn@zewt.org>, "Jonas Sicking" <jonas@sicking.cc>, "Kyle Huey" <me@kylehuey.com>, public-webapps@w3.org
Message-ID: <op.v2mnankj64w2qv@annevk-macbookpro.local>
On Thu, 29 Sep 2011 23:17:21 +0200, Eric U <ericu@google.com> wrote:
> I think that works; #2 will be especially important.
> However, if I read this right, we *don't* have the invariant that a
> loadstart will always have a loadend.
> Now that Anne's explained XHR2's model, it seems that an open can
> cancel the loadend that an abort would have sent.  So the invariants
> need to be a bit more complex.

Well lets not accept as XHR2 as set-in-stone.

We could also change XHR2 to not cancel abort() when invoking open(). Then  
you get scenarios such as:

   abort()
   -> abort event that invokes open()
      -> readystatechange event
   -> loadend event
   -> abort event on XHRUpload
   -> loadend event on XHRUpload

Instead of everything after the readystatechange event not happening. We  
could also introduce a flag and make it impossible to call open() from an  
event handler.

Maybe the simplest is the above. You can call open() from event handlers,  
but events will still be dispatched (and readyState will have changed).  
This is somewhat ugly, but then you should probably not invoke open() from  
event handlers anyway.


-- 
Anne van Kesteren
http://annevankesteren.nl/
Received on Friday, 30 September 2011 15:15:08 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:47 GMT