Rand Scullard Reporter
	Description • 16 years ago

User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 1.0.3705; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648; Zune 2.5)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0

In Firefox 2 (as well as Internet Explorer and Safari), making a synchronous AJAX request via XMLHttpRequest causes the user interface to block until the request returns. That is, the user cannot interact with any user interface elements in the web page during the synchronous call.

Firefox 3 breaks this behavior. The same web page allows user interface interactions even while the supposedly synchronous call is in progress. The attached URL points to a page that demonstrates this.

Please note that the Mozilla documentation (http://developer.mozilla.org/en/docs/XMLHttpRequest) states "This example works synchronously, so it will block the user interface if you call this from your JavaScript" and also "Firefox 3 blocks until the request is completed."

We have a proprietary AJAX framework that supports mission-critical applications at some very large corporate clients. This framework depends on proper synchronous (UI-blocking) behavior for certain operations to work correctly. It functions properly on IE, Safari, and Firefox 2, but is broken on Firefox 3. Our clients will not be able to upgrade to Firefox 3 unless this issue is resolved or a workaround is discovered.

Reproducible: Always

Steps to Reproduce:
1. Browse to: https://software.guptonmarrs.com/onyxdev/Ext/_TestApp/Pages/Firefox3SyncAjaxBug.aspx

2. Click the first button (labeled "Click here to make a 5-second synchronous AJAX call").

3. Immediately click the second button (labeled "This shouldn't respond to a click while the AJAX call is running"). Click it a few times.
Actual Results:  
In Firefox 3, clicking the second button (labeled "This shouldn't respond to a click while the AJAX call is running") will immediately display a message box saying "You clicked it!", even though a synchronous call is in progress. Then, when the AJAX call completes, you will see a message box saying "AJAX call returned!"

Expected Results:  
In Firefox 2, clicking the second button (labeled "This shouldn't respond to a click while the AJAX call is running") has no effect while the synchronous AJAX call is in progress. Then, when the AJAX call completes, you will see a message box saying "AJAX call returned!" THIS IS THE CORRECT BEHAVIOR.

	Ria Klaassen (not reading all bugmail)
	Comment 1 • 16 years ago

Duplicate of Bug 333198 ?

	Ria Klaassen (not reading all bugmail)
	Comment 2 • 16 years ago

This bug was probably caused by bug 326273.

	Boris Zbarsky [:bzbarsky]
	Comment 3 • 16 years ago

Yep.  The whole point of thread manager was that spinning an event queue should NOT block UI events.  Doing that (the old behavior) caused a number of highly undesirable effects.  This bug does sound like bug 333198 to me, indeed.

And perhaps the documentation should be updated.  I don't think we've ever guaranteed that the browser UI would be blocked (e.g. that a user wouldn't be able to navigate away from the page during the sync load), nor do I think we should ever guarantee such a thing.

	Boris Zbarsky [:bzbarsky]
	Comment 4 • 16 years ago

Note that I seriously doubt changes to behavior of this sort can happen on a stable branch...  I really wish someone had reported this sometime during the numerous alphas and betas.  :(

	Rand Scullard Reporter
	Comment 5 • 16 years ago

I would like to make several comments about this outcome:

- You have defined blocking UI events as causing a number of "highly undesirable" effects. I submit that whether these effects are "undesirable" is up to the developer of the web site, who has explicitly chosen synchronous behavior. Consider that the XMLHttpRequest API provides both async and sync request types. If the web developer wants non-blocking behavior, the async request has always been available to satisfy that need, and it does so very well. In those particular circumstances where UI blocking is required, the sync request has provided that capability. What Firefox 3 has done is redefine the behavior of the sync request to be more like the async one... but since we already had perfectly fine async functionality at our disposal, whose needs does this change satisfy? Even if you think this is a change for the better, it is nevertheless a change that puts Firefox at odds with every other major browser. Inconsistencies between browsers (all of which we must support, whether we like it or not) don't make the web developer's job any easier. Finally, and perhaps most important, it is a change that cannot be worked around by the web developer: There is no API option to revert to the old UI-blocking behavior, and there does not seem to be any way to for a web page to simulate the old behavior.

- You have marked this bug as a duplicate of bug 333198. That other bug has an almost content-free description, no repro case, and no explanation of the impact of this bug on real, running web applications. There has been no activity on bug 333198 in over a year. May I respectfully suggest that this disposition may not be the best way to make progress on this issue?

- I agree that it is regrettable that this issue was not reported during the alpha and beta process. However regrettable this is, it doesn't change the fact that existing web sites that depend on synchronous behavior will break under Firefox 3. The question is how best to move forward.

	Boris Zbarsky [:bzbarsky]
	Comment 6 • 16 years ago

Rand, the "undesirable effects" are from blocking events in the browser user interface.  That's none of the website author's business, to be honest.  A website cannot be allowed to prevent the user from interacting with the browser to, e.g., close the website.

I fully agree with you that interaction with the web page should be blocked, and that's what bug 333198 is about.  The problem is that such changes are very likely to cause other things to break, so the best way to move forward may well be to fix this issue in Firefox 3.1 or even Firefox 4 at this point... it's the sort of thing that is likely to need at least 3-4 months of testing to shake out the problems.  :(

	Rand Scullard Reporter
	Comment 7 • 16 years ago

Most browsers block the entire UI during a synchronous call, but if you have a way to block just the web page without blocking the rest of the UI, that would be an excellent solution indeed.

The un-blocked portions of the browser UI would still have the potential to interact with the (blocked) web page. How would you handle a case like the user resizing the browser window during a sync call? Would you queue the resize event and dispatch it when the sync call completes? (Thus maintaining the same behavior - from the script's perspective - as a totally-blocked browser.)

Obviously I don't expect you to make any kind of commitment, but given the fact that bug 333198 was reported over two years ago, it seems reasonable to ask: Is there any likelihood that this issue will be addressed in the near future?

	Boris Zbarsky [:bzbarsky]
	Comment 8 • 16 years ago

Honestly, I don't know.  The current behavior is a result of a major redesign about three years ago, and the guy who did the redesign is no longer around...

	Ingo Koch
	Comment 10 • 16 years ago

We also would embrace very strongly a solution to this problem the way it is
described above because it also breaks our web applications so that we have to
fall back to other mechanisms which cause performance issues and other
problems.

	herve
	Comment 11 • 16 years ago

I also experienced this kind of problem (only on FF3).
Somwhere in a html page I get a value by calling a xmlhttprequest synchronously.
I want to use this value somwhere further in the html page but the value is still undefined or is set to a precedent value.
This behaviour doesn't occur each time but only 1 time on 20 or 50.