W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

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

From: Arun Ranganathan <arun@mozilla.com>
Date: Mon, 03 Oct 2011 16:01:56 -0400
Message-ID: <4E8A14B4.6080202@mozilla.com>
To: Anne van Kesteren <annevk@opera.com>
CC: Eric U <ericu@google.com>, Glenn Maynard <glenn@zewt.org>, Jonas Sicking <jonas@sicking.cc>, Kyle Huey <me@kylehuey.com>, public-webapps@w3.org
On 9/30/11 11:14 AM, Anne van Kesteren wrote:
> 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.


This gives us the desirable invariant that a loadstart will always have 
a loadend, which I think simplifies this model.  It seems useful to 
proceed with this in FileAPI.

-- A*



>
>
Received on Monday, 3 October 2011 20:02:38 GMT

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