- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 3 Oct 2011 15:00:36 -0700
- To: Anne van Kesteren <annevk@opera.com>
- Cc: arun@mozilla.com, Eric U <ericu@google.com>, Glenn Maynard <glenn@zewt.org>, Kyle Huey <me@kylehuey.com>, public-webapps@w3.org
On Fri, Sep 30, 2011 at 8:14 AM, Anne van Kesteren <annevk@opera.com> 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. Unfortunately I suspect wanting to call open from event handlers is a pretty common use case. Here are two use cases: 1. In case of a network error, let the onerror handler retry the request. 2. Implementing a auto-complete UI backed by data stored on the server. Any time the user hits another character, abort the current request and perform a new request with the newly typed value. In the first case it makes sense to call .open/.send from the onerror handler. In the second case it makes sense to do so from the onabort handler. I'm personally split on the issue. On one hand I really like the simplicity of saying that each "loadstart" is always paired with a "loadend". On the other hand, I have a hard time thinking of any use cases which *wouldn't* be helped by simply dropping the "loadend" event if a new load had been started. For example if you're implementing a progress bar, it would be very easy to make the mistake of hiding the progress bar from "loadend" and showing it in "loadstart". In the two use cases above, that would result in the progress bar not showing during the second load. I'll leave as an exercise to the reader how to avoid such a bug ;-) / Jonas
Received on Monday, 3 October 2011 22:01:36 UTC