#1640 closed defect (fixed)
sync XmlHttpRequest freeze Firefox 1.5
| Reported by: | Owned by: | alex | |
|---|---|---|---|
| Priority: | high | Milestone: | |
| Component: | IO | Version: | 0.3 |
| Keywords: | Cc: | ||
| Blocked By: | Blocking: |
Description
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(); http.open('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 13 years ago by
| Version: | 0.4 → 0.3 |
|---|
comment:2 Changed 13 years ago by
I disabled it, and I still have the issue.
(sorry for the bug report layout, I used Submit instead of Preview)
comment:3 Changed 13 years ago by
| Component: | Core → IO |
|---|---|
| Milestone: | → 0.4 |
| Owner: | changed from anonymous to alex |
Should this block 0.4?
comment:4 Changed 13 years ago by
I can confirm with the test page here:
http://dojotoolkit.org/~jburke/dj4/dojo/tests/hang/hang.html
This test page does a dojo.require() instead of a direct sync request (still sync request underneath), and it hangs too:
http://dojotoolkit.org/~jburke/dj4/dojo/tests/hang/hang2.html
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):
http://dojotoolkit.org/~jburke/dj4/dojo/tests/hang/hang3.html
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 13 years ago by
| severity: | normal → blocker |
|---|
comment:6 Changed 13 years ago by
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 1.5.0.7, OSX 10.4, same config as previous changes):
http://dojotoolkit.org/~jburke/0.3.1-ajax/tests/hang/hang.html
comment:7 Changed 13 years ago by
comment:8 Changed 13 years ago by
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
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
do you use firebug?
if so, try to disable it and see whether you still have this issue