Re: Synchronous XMLHttpRequest and events

On Fri, May 13, 2011 at 3:07 PM, Olli Pettay <Olli.Pettay@helsinki.fi> wrote:
> 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.

Yeah, I think we can get away with this.

The one case where it seems that Gecko and the spec differentiate for
the readystatechange event is that gecko dispatches readystatechange
when going to the DONE state even if the network request failed during
a sync-load. The spec only dispatches it for successful loads.

In other words, Gecko always dispatches readystatechange (with
.readyState set to 4) before send() returns.

/ Jonas

Received on Friday, 13 May 2011 22:18:53 UTC