Do Sync Calls Freeze Browsers?

by Mark Pruett

In a recent blog entry, "The Hardware of Tomorrow Versus the Platform of Tomorrow", Joe Walker raised some important Ajax issues. He talks about the increasing multiprocessing capabilities of today's hardware, and web browsers' inability to take full advantage of it.

He mixes two separate issues, talking about the lack of threading/concurrency support in the Javascript language, and also the lack of multi-threading within web browsers.
It's this second issue that I want to explore here, particularly this comment:

"The problem is that web-browsers are a step backwards as far as multi-threading goes. In Javascript there is no such thing as a new thread, and worse than that, the entire platform (i.e. a browser) runs a single JavaScript thread. If a script in one window goes into a tight loop, or runs some synchronous Ajax then the browser HTML display freezes."

Hmmm. That last sentence started gnawing at me. I'll leave the "tight loop" problem for another day, but is it true that a synchronous XMLHttpRequest call will "freeze" the browser?


M. David Peterson
2007-01-28 10:55:01
This is really interesting, Mark. Thanks for the data (and the work that went into gathering it)!
Mark Pruett
2007-01-28 17:04:07
An Update: Since posting, I've read that the sync-freezing problem is resolved in Moz/Firefox nightly builds. I downloaded the trunk build for Linux (Firefox Minefield/3.0a2pre) and ran my tests. Sure enough -- no more freeze! So it looks like this problem will be history for all major browsers with the next Firefox release.
2007-01-28 22:46:20
thank god, i am waiting for firefox to release the updates.... in one of my projects i needed to make sync call but as it freezes the firefox i had to look for lengthy way to handle this situation... :(
Paul B
2007-01-29 09:35:17
I quite often experience Firefox freezes (I'm currently on; experience has taught me to associate them with certain sites and/or conditions, which I now tend to avoid when possible. I find it quite frustrating that the entire app hangs while waiting on one tab/connection.
Jeremy Dunck
2007-01-29 14:13:48
For the IE test, make sure you have multiple windows in a single process.

Starting IE from a shortcut or command line starts a new process, while using "new window" within the IE window runs the second window in the same process.

This may affect your results.

Harry Fuecks
2007-01-30 05:14:31
Seems that some messages just aren't getting through. Been banging this drum since May 2005. A demo:

Otherwise ...

Alex Osipov
2007-01-30 11:20:01
Hello Mark - I hope you can explore this a little further. If you read my posts at regarding a similar issue with javascript you will notice synchronous calls will break thread safety in javascript. I believe the same bug you describe as fixed in a development build of Firefox was responsible for maintaining safety of data and IE and Opera do not block synchronous calls properly.

The reason why your synchronous calls should be frozen across browsers within the same process is to make sure that concurrency issues to do arise. If this is "fixed" then I think there will be more problems. After all a synchronous call should block all further execution until it is returned.

I realize your example does not use child windows but you simply did an Open New Window but you can understand the need for proper fix here. Windows that do not have any children or parents should not block other windows. However, windows with parents and/or children should definitely be blocking calls.

My 2 cents.

Jess Sightler
2007-01-31 14:34:07
Er, does anyone really still use synchronous xmlhttprequest calls? They seem rather pointless in JS to me.
Vincent Jacquet
2007-01-31 23:31:22
Thanks, this is quite informative. I also find it very motivating when someone reminds me about not to take anything for granted and to look out for the facts behind the speech.

On need of doing synchronous calls, I think that if a developer ends up in a situation in which he needs synchronous call, he'd better think again because he whould have completely missed the point of Asynchronous JavaScript and XML.
As a user, what I hate the most is when my user interface freezes. Coding asynchronously is harder and a little more work, but at the end it is worthwhile for the user experience. If you need data, say it to the user, if you need to wait for the result of an action before being able to allow a new one, disable the buttons or links, and say it.

You cannot ensure concurrency by "freezing" the page, or even the application. What if, because you froze the firefox of your user, he opens an Internet Explorer to continue working and ends up doing the exact action you wanted to prevent ?

Mark Pruett
2007-02-01 05:59:40

"On need of doing synchronous calls, I think that if a developer ends up in a situation in which he needs synchronous call, he'd better think again because he whould have completely missed the point of Asynchronous JavaScript and XML. As a user, what I hate the most is when my user interface freezes."


I agree 100% that synchronous calls should be avoided. But if you do use them, you should know how they'll affect browsers. I'd read that sync calls froze browsers, but didn't recall that being true for Opera. I guess my big unspoken point in all of this was: When in doubt, experiment.

Vincent Jacquet
2007-02-01 08:55:47
This is why I really appreciate your post.
2007-03-01 10:47:23
It will be interesting if you repeat this experiment with two frames instead of two windows.

I find that Opera 9 allows interaction with user and between frames even if one of frames is busy in endless loop, while IE 6 and FF 1.5 doesn't. This experiment didn't involve XMLHttpRequest.

John Peterson
2007-03-07 14:14:54
anyone mind sharing a cross-browser version (FF+IE) of a synchronous ajax call that actually works? thanks!
2007-03-12 17:27:28
John - Use a Javascript toolkit like Dojo:{ url: '/test.php' });

2007-03-12 17:28:01
Oops - you wanted synchronous:{ url: '/test.php', sync: true });

Mark Pruett
2007-03-13 05:03:37

This code has worked well for me for creating a cross-browser XMLHttpRequest object. Is there something beyond this (related to sync calls) that's causing a problem?

// Browser-neutral creation of an XMLHttpRequest object.
function getHTTPObject() {
var xmlhttp;
@if (@_jscript_version >= 5)
try {
xmlhttp = new ActiveXObject("Msxml2.XMLHTTP");
} catch (e) {
try {
xmlhttp = new ActiveXObject("Microsoft.XMLHTTP");
} catch (E) {
xmlhttp = false;
xmlhttp = false;
@end @*/
if (!xmlhttp && typeof XMLHttpRequest != 'undefined') {
try {
xmlhttp = new XMLHttpRequest();
} catch (e) {
xmlhttp = false;
return xmlhttp;