Re: [XHR]

On Mon, Oct 8, 2012 at 4:06 AM, Jakub Łopuszański <qbolec@gmail.com> wrote:

> 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.
>

Replacing the delay with an alert() dialog, and pointing the fetch at a 1MB
file, I can't reproduce this.  Each readystatechange has the correct
readyState value at the time: only a single event sees each of OPENED,
HEADERS_RECEIVED and DONE, and (in my particular case) about 16 LOADING
events.  This is what the spec requires.

(If it happens when the debugger is involved, that's probably a bug in
Chrome, but it's not an issue with the spec.)

On Mon, Oct 8, 2012 at 9:42 AM, Jakub Łopuszański <qbolec@gmail.com> wrote:

> 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.


This can't happen; there's no such thing as "firing events too fast".  If
an event handlers blocks, no other events can be fired until it returns,
because the thread is blocked.

-- 
Glenn Maynard