- From: Arun Ranganathan <arun@mozilla.com>
- Date: Fri, 30 Sep 2011 13:15:17 -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. Anne: I think simplifying the model like this makes sense, although previous discussions seemed to suggest that previous implementation history made these kinds of changes hard. I'd be happy to match this in FileReader if that's what you're doing in XHR2. I'm interested in hearing from Glenn, Jonas, and others, but I think Eric's on paternity leave so we'll have to channel him w.r.t. FileSaver/FileWriter :) -- A*
Received on Friday, 30 September 2011 17:15:48 UTC