On Mon, Oct 8, 2012 at 4:06 AM, Jakub Łopuszański <qbo...@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 <qbo...@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