Open Bug 460366 Opened 12 years ago Updated 2 years ago

Opening a modal window interferes with synchronous XHR


(Core :: DOM: Core & HTML, defect, P5)






(Reporter: dcradler, Unassigned)



(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/2008092417 Firefox/3.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/2008092417 Firefox/3.0.3

If a synchronous XHR operation is in progress and an alert or modal window is opened, the XHR does not complete until the window is closed. Either it should not open the window in this case (block UI events) or the request should be allowed to complete. This is a problem in web applications where the user can have multiple windows open - one window may have an XHR request going and in another an alert pops up. This causes the window with the XHR request active to freeze until the alert is closed. Note this is only an issue with synchronous XHR - async works fine.

Reproducible: Always

Steps to Reproduce:
1. Open two windows
2. Start synchronous XHR in one window that will take a few seconds to complete and give some visual indication it is done
3. In second window open a javascript alert.
4. Note that XHR request is stuck while alert is up
5. Close the alert in second window and XHR request completes in the first window
Actual Results:  
XHR request was stuck while alert was up - that window is basically hung.

Expected Results:  
Either FF should prevent the alert from opening in first place (less desired) or it should let the sync XHR call complete (more desired). A UI event in one window should not interfere with XHR in another window.

I can provide a code sample if this doesn't make sense.
> I can provide a code sample

Yes, please.
Attached file Test code for this bug
See contents of attached document for instructions. You will need some simple server-side routine that has a sleep or wait in it to test this.
A further problem which seems to be related is that if you have sync XHR requests running in two different windows, the shorter running request does not return control to JS until after both requests have completed. The same test case can be used to see this - start a request in one window, wait a couple of seconds, then start a request in the second window. Both return control to JS at the same time, when the second request completes.
One more major issue - a similar blocking problem exists for any modal window including JS alerts. If you display an alert in a window and another alert comes up in a second window, both alerts must be closed before code execution continues in either window. The same same code sample I provided demonstrates this problem as well. I can see this causing problems with web applications that might display JS alerts or modal prompts of any sort. These sorts of irritations might drive some users to Google Chrome which keeps one application window or tab from affecting another. FF3.1 beta 1 still has the same problems.
I'm guessing this is actually the same problem as Bug 61098 - modal dialogs (and apparently synchronous HTTP requests) block the entire Firefox app from executing JavaScript instead of just the current tab or window. Hopefully it will be fixed someday so these things are content-modal.
OS: Windows XP → All
Hardware: PC → All
Version: unspecified → Trunk
Component: General → Tabbed Browser
QA Contact: general → tabbed.browser
Component: Tabbed Browser → DOM
Product: Firefox → Core
QA Contact: tabbed.browser → general

Move all DOM bugs that haven't been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.
Priority: -- → P5
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.