W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2012

Re: [XHR]

From: Glenn Maynard <glenn@zewt.org>
Date: Mon, 8 Oct 2012 10:25:54 -0500
Message-ID: <CABirCh94OQ3fASMqYQrrV2K_=Yt=e==qdAxrDGGcbQOr+mMpFA@mail.gmail.com>
To: Jakub Łopuszański <qbolec@gmail.com>
Cc: "Hallvord R. M. Steen" <hallvord@opera.com>, public-webapps@w3.org
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
Received on Monday, 8 October 2012 15:26:22 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:55 GMT