Opened 15 years ago

Closed 15 years ago

Last modified 14 years ago

#1640 closed defect (fixed)

sync XmlHttpRequest freeze Firefox 1.5

Reported by: [email protected] Owned by: alex
Priority: high Milestone:
Component: IO Version: 0.3
Keywords: Cc:
Blocked By: Blocking:


Browser : Firefox 1.5 (config : default [keep-alive activated, network.http.max-persistent-connections-per-server : 2])

DOJO version : HEAD

Using a synchronous XMLHttpRequest while loading a big enough document ( greater than 65536 bytes) create a dead-lock : FF wait for server response for its XMLHttpRequest and the server waits for FF to read the content (document data)

This code helps to reproduce the bug <html> <head> <script src="dojo/dojo.js.uncompressed.js"></script> <script> function docLoaded() { var http = dojo.hostenv.getXmlhttpObject();'GET',"document.xml", false);

alert("Calling sync XMLHttpRequest - it's gonna freeze ..."); http.send(null); alert("Well, i guess they've fixed it, response (first fragment ) is " + http.responseText.substring(0, 255)); }

if (document.addEventListener) document.addEventListener("DOMContentLoaded", docLoaded, false);

</script> </head> <body> <img src="img/Sunset.jpg" width="100" /> <img src="img/Sunset1.jpg" width="100" /> <img src="img/Sunset2.jpg" width="100" /> <img src="img/Sunset3.jpg" width="100" /> <img src="img/Sunset4.jpg" width="100" /> </body> </html>

This is not only a DOJO problem, but you can reproduce it with DOJO : DOJO loads "required JS files" (and HTML templates) synchronously,

Ex : Try to load an HTML page (using dojo) with 2 images (the number corresponds to the number of persistent connections allowed by firefox) whom size are greater than 65536 bytes (because FF loads 64Kb before allowing the server to send other response) , you will freeze FF

This bug only appears on the HEAD version because 0.3 version does not seem to use DOMContentLoaded, and window.onLoad wait for images complete loading. (which is bad for DOJO perf.)

However I think we can reproduce it with another test case in 0.3 (maybe loading dynamically big images after FF page loading)

Change History (9)

comment:1 Changed 15 years ago by liucougar

Version: 0.40.3

do you use firebug?

if so, try to disable it and see whether you still have this issue

comment:2 Changed 15 years ago by [email protected]

I disabled it, and I still have the issue.

(sorry for the bug report layout, I used Submit instead of Preview)

comment:3 Changed 15 years ago by dylan

Component: CoreIO
Milestone: 0.4
Owner: changed from anonymous to alex

Should this block 0.4?

comment:4 Changed 15 years ago by James Burke

I can confirm with the test page here:

This test page does a dojo.require() instead of a direct sync request (still sync request underneath), and it hangs too:

This page uses window onload to do the dojo.require, and it works (an error happens but that is a widget issue, not a loading issue):

We could revert back to window.onload for Firefox only. Maybe we could talk with someone at Mozilla about the problem too. Seems like it would be odd that this locks up like this.

comment:5 Changed 15 years ago by dylan

severity: normalblocker

comment:6 Changed 15 years ago by James Burke

I tested with Dojo 0.3.1 with an ajax build (an ajax build is used for the pre 0.4 tests above). I worked fine (Firefox, OSX 10.4, same config as previous changes):

comment:7 Changed 15 years ago by James Burke

(In [6258]) References #1640. Use a flag to get around FF synch loading issue as described in the bug. Allows us to go ahead with 0.4 now, and advise folks to use djConfig switch for FF if they see a problem loading.

comment:8 Changed 15 years ago by James Burke

Resolution: fixed
Status: newclosed

We have a workaround for apps that hit this issue (a djConfig flag). It was agreed to close this bug and track an investigation with Mozilla in Trac #1704

comment:9 Changed 14 years ago by (none)

Milestone: 0.4

Milestone 0.4 deleted

Note: See TracTickets for help on using tickets.