2012/10/8 Hallvord R. M. Steen <[email protected]> > Jakub Łopuszański <[email protected]> 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 >
