Re: [XHR]

2012/10/8 Hallvord R. M. Steen <hallvord@opera.com>

> Jakub Łopuszański <qbolec@gmail.com> skreiv Sat, 06 Oct 2012 18:09:16
> +0200
>
>
>  Spec at http://www.w3.org/TR/**XMLHttpRequest/<http://www.w3.org/TR/XMLHttpRequest/>says that:
>> 1. each change of state must fire an event
>> 2. readyState must always be equal to the current state
>> it follows that it is possible for eventhandler to be called more than
>> once with the same value of readyState
>>
>
> You mean a race condition of sorts where the implementation fires an event
> for the change from readyState 2 to readyState 3 but when the event gets
> fired, readyState turns out to be 4 already? An implementation doing that
> is not likely to be web-compatible, so if the spec text seems to allow this
> we should probably fix it. (There was however at least one implementation
> that supported a sort of server-push mode by supporting chunked HTTP and
> firing a new readyState 3 event every time a new part of the content came
> in - I think Firefox used to do this but I'm not sure if they still do.) So
> I don't know if we really want to outlaw firing several events for the same
> readyState value..


Yes, I mean this race condition. It actually is quite easy to reproduce
-- open http://jsfiddle.net/44b3P/ in Chrome with dev tools opened. I've
added "debugger" statement to force a pause long enough for events to
accumulate in the queue, so once you press "play" button to continue
debugging, you'll get 3 alerts one for each event.



>
>
>
> --
> Hallvord R. M. Steen
> Core tester, Opera Software
>