Re: [XHR]

2012/10/8 Jungkee Song <jungkee.song@samsung.com>

> > 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
>
>
I used "debugger" as it was the easiest way for me to show whats wrong with
the example presented in the W3C documentation -- I've simply added one
line, and viola!
In real word scenario consider sending multiple requests to files cached in
broswer's cache -- I believe it may happen that they all return almost
immediately, firing events faster than JS can execute eventhandlers for
them, if eventhandlers perform some complicated blocking actions.

I do not know if I understand correctly what you say, but I hope it was not
"race conditions are rare, so why change the spec".
Yes, they are rare, but w3c spec should be the place where developers can
find a rock solid example of code.
In this case it would suffice to add some boolean guard, or just check if
the current status is actually different than the last observed one.
I am not arguing to change the behaviour of XHR, but rather to change the
example.