- From: Olli Pettay <Olli.Pettay@helsinki.fi>
- Date: Sat, 14 May 2011 01:07:11 +0300
- To: public-webapps@w3.org
- CC: Jonas Sicking <jonas@sicking.cc>, Boris Zbarsky <bzbarsky@mit.edu>
On 05/13/2011 11:54 PM, Olli Pettay 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. To clarify this, it is ok to dispatch events before the actual processing starts (network connection opens etc) and after UA has gotten the result but hasn't returned control to the caller. -Olli > >> >> / Jonas >> >> > > >
Received on Friday, 13 May 2011 22:07:42 UTC