Closed Bug 444457 Opened 12 years ago Closed 12 years ago

Synchronous AJAX requests (via XMLHttpRequest) do not block the Firefox 3 user interface

Categories

(Core :: XML, defect, major)

defect
Not set
major

Tracking

()

RESOLVED DUPLICATE of bug 333198

People

(Reporter: rand_scullard, Unassigned)

References

()

Details

(Keywords: regression, testcase)

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.
This bug was probably caused by bug 326273.
Status: UNCONFIRMED → NEW
Component: General → XML
Ever confirmed: true
Keywords: regression, testcase
Product: Firefox → Core
QA Contact: general → xml
Version: unspecified → Trunk
Flags: wanted1.9.1?
Flags: wanted1.9.0.x?
Flags: blocking1.9.1?
Flags: blocking1.9.0.2?
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.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 333198
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.  :(
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.
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.  :(
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?
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...
Flags: wanted1.9.1?
Flags: wanted1.9.0.x?
Flags: blocking1.9.1?
Flags: blocking1.9.0.2?
Duplicate of this bug: 445714
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.
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.
You need to log in before you can comment on or make changes to this bug.