W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2012

Re: [XHR]

From: Jakub Łopuszański <qbolec@gmail.com>
Date: Mon, 8 Oct 2012 11:06:40 +0200
Message-ID: <CAC=6dzA99jiUX6R0dxPM+kz+xzd_t6kaGEegDh02_rznSna3mg@mail.gmail.com>
To: "Hallvord R. M. Steen" <hallvord@opera.com>
Cc: public-webapps@w3.org
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
Received on Monday, 8 October 2012 09:07:12 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:49 UTC