- From: James Robinson <jamesr@google.com>
- Date: Fri, 13 May 2011 15:02:50 -0700
- To: Olli@pettay.fi
- Cc: Jonas Sicking <jonas@sicking.cc>, Boris Zbarsky <bzbarsky@mit.edu>, public-webapps@w3.org
Received on Friday, 13 May 2011 22:03:18 UTC
On Fri, May 13, 2011 at 1:54 PM, Olli Pettay <Olli.Pettay@helsinki.fi>wrote: > On 05/13/2011 11:39 PM, Jonas Sicking wrote: > >> On Fri, May 13, 2011 at 1:21 PM, Boris Zbarsky<bzbarsky@mit.edu> wrote: >> >>> On 5/13/11 4:07 PM, Jonas Sicking wrote: >>> >>>> >>>> It *does* however call for a readystatechange event to be fired in >>>> response to the call to .open. Even if the request being started is a >>>> synchronous one. >>>> >>>> What is the use case for this event? It seems pretty useless and >>>> inconsistent to me. >>>> >>> >>> I believe web pages depend on this to some extent; the fact that Gecko >>> used >>> to not fire it caused all sorts of compat issues. See >>> https://bugzilla.mozilla.org/show_bug.cgi?id=313646 >>> >> >> Ugh, yeah, in testing my patch I came across the same bug. >> >> So it appears the spec needs to be adjusted the other direction then. >> It needs to define that readystatechange needs to fire in all cases >> independent of the value of the asynchronous flag? >> > > No. We don't want to fire any events *during* sync XHR processing. > I would definitely prefer not to on philosophical grounds, but I think it's required for compatibility and that trumps theoretical purity. The spec should document reality. - James > > > -Olli > > > >> / Jonas >> >> >> > >
Received on Friday, 13 May 2011 22:03:18 UTC