- From: Arun Ranganathan <arun@mozilla.com>
- Date: Mon, 03 Oct 2011 16:01:56 -0400
- 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 UTC