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 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:49 UTC