Closed Bug 444457 Opened 12 years ago Closed 12 years ago
Synchronous AJAX requests (via XMLHttp
Request) do not block the Firefox 3 user interface
Duplicate of Bug 333198 ?
This bug was probably caused by bug 326273.
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...
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.