- From: Hallvord R. M. Steen <hallvord@opera.com>
- Date: Mon, 08 Oct 2012 10:43:46 +0200
- To: public-webapps@w3.org, Jakub Łopuszański <qbolec@gmail.com>
Jakub Łopuszański <qbolec@gmail.com> skreiv Sat, 06 Oct 2012 18:09:16 +0200 > Spec at 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.. -- Hallvord R. M. Steen Core tester, Opera Software
Received on Monday, 8 October 2012 08:44:51 UTC