Firefox 3.5 and XmlHttpRequest

[Eoghan]

I'm noticing a problem using a deferred with firefox 3.5.

I have a bit of javascript at the bottom of the html to synthesize a
domload event (but I have also reproduced this behaviour with a plain
window.onload event) and fire off an AJAX request :

....
<script type="text/javascript">signal(window, 'onDOMload');</
script>
</body></html>

file.js :

connect(window, 'onDOMload', function(e){
var loadc = loadJSONDoc("/test");
loadc.addCallback(function(r){ log('success'); });
loadc.addErrback(function(r){ log('error'); });
});

Most of the time in firefox 3.5 nothing at all gets logged ... you can
see that the JSON response was returned correctly in firebug, but
neither the callback or errback fires. The status of 'loadc' is
'success'.

It appears to work correctly in both Chrome and IE8.
When I downgrade firefox to 3.0.11 it also runs as expected.

Anyone else seeing anything similar?

I have a feeling that it has something to do with that I'm firing off
the request early, while the rest of the page is loading... I've used
callLater to delay the request, and see the same behaviour but much
less freequently.

Eoghan

[Karl Norby]

I ran your test in FF3.5, and I ended up seeing no log entry in about
1 of every 10 trials, although I saw the request every time in
firebug. I changed your test around to use body onload instead, and it
works fine every time I test it. Since the requests seem to be going
through, signal.js is loading every time before signal is called, but
logging probably is not (loaded much later than signal). If I change
'log' to 'alert' in your example, the problem doesn't persist.
So, even if FF loads all of the scripts in head in the correct order,
script tags in body can be loaded at any point of that process, thus
creating the race condition. That's probably a bug in firefox then, as
I can't think of why that behavior would be desirable.

Cheers!

-Karl

[Eoghan Murray]

Thanks for reproducing :)

I've originally encountered the bug with a packed version of MochiKit;
in that case, Signal.connect firing implies that the rest of MochiKit
is available including logging.

I've also tested it with connect(window, 'onload', ... ) where it
occurs less frequently.

I've quite a number of images on the page, and it seems to occur more
frequently if I do a full cache reload of the page.

Here it is 'in the wild': http://gs.statcounter.com/
(MochiKit.Logging is not enabled; if the bug occurs the flash graph
will not load)

Eoghan