RE: [XHR]

> From: Jakub Łopuszański [mailto:qbolec@gmail.com] 
> Sent: Monday, October 08, 2012 6:07 PM
>
> 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/ 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.

Although we can reproduce this executing *debugger;* statement in Web
Inspector, there might not be many such cases in real web programming
context. This particular case may represent the situation in that a client
wants to *block* the execution until the data transfer completes. I believe
"block" the execution in asynchronous request is not that client
implementation normally intends. (I don't think we have any JavaScript
function to do so.)

If client intentionally needs to be blocked, it should make a synchronous
request although it may encounter browser popup to abort the request:
client.open("GET", "too-big-to-wait-image.png", false);
client.send();

I believe the statement in the spec, "The XMLHttpRequest object can be in
several states. The readyState attribute must return the current state,
...", sounds reasonable assuming non-blocking scenarios. It also supports
the use case that Hallvord mentioned above.

Regards,
Jungkee

Jungkee Song
Samsung Electronics

Received on Monday, 8 October 2012 12:57:05 UTC