From Bugzilla Helper: User-Agent: Mozilla/4.72 [en] (WinNT; U) BuildID: 2000051820 I was browsing through bugzilla, and I guess it was overloaded, because I got an "Alert: bonsai.mozilla.org could not be found ...". The odd thing is that the dialog doesn't have the focus. The main mozilla window does. However, the alert box is a modal dialog. I can't transfer focus to the modal dialog, and I can't do anything in the main mozilla window. The windows are repainting, I just can't do anything. The application is essentially "hung", even though it hasn't crashed. I'll have to kill it and restart. Reproducible: Didn't try

related to bug 39439 "modal dialogs become inaccessible" ?

This seems to be the same thing that happens with bug 36172.

updating component and owner.

I haven't seen this, and there are no steps to reproduce. It may be a dup of one of the bugs listed above, but only the reporter could say for sure. resolving as wmf, please reopen when/if you get a reproducible case.

I have a process that usually succeeds in duplicating this bug. I use a "virtual window manager" called JSPager (http: //hem.fyristorg.com/jspage/). I wouldn't be surprised if other VWMs for Windows would work similarly. While running JSPager, I run Mozilla in one workspace. I start the "browser buster" and then change workspaces to somewhere else, so Mozilla is not visible. Eventually, one of the pages will get a transient connection problem and fail to connect, giving me an error dialog (often referencing "komodo.mozilla.org"), although I often don't notice it when it appears. When I eventually notice the error dialog, I find it is in this state where the dialog is modal, but it does not have the focus. The main mozilla window has the focus, but I can't select it, and neither can I dismiss the error dialog. The "browser buster" is still running, loading a new page every 25 or so seconds. I have no alternative but to kill mozilla.

See also bug 36172 (problem with another workspace switching program or two). dkarr: When the dialog gets inaccessible, the workaround is to minimize it from "Task Manager" and then restore it. Most of the time the dialog will now be working again.

assigning to danm as p3 for future

I can reproduce a similar situation using bug 45108 on win NT 4 with M16: 1. Select "Edit" in the menubar 2. Move mouse down to "Preferences", but don't press mouse button yet 3. Press winkey-m (menu will stay on screen due to bug 45108) 4. Select "Preferences" 5. Press winkey-shift-m 6. Select mozilla in windows taskbar to bring it back to top Result: Main mozilla window seems to have focus (indicated by highlighted titlebar), but does not respond and is not the top window. Preferences window is top window but does not have full focus. Radio buttons behave strange and you can't get rid of this window. You'll have to kill mozilla. Don't know if this is really an aspect of bug 39841, but i think so.

I don't know if this is steps to repro or another bug, and I can't reproduce it on my build because I've hooped something. But I did run into it about a week ago. Open a browser window. Select Edit > Preferences > Themes, then Classic. The home page should be Ben's old page. Click the home page button. The browser window in behind becomes active, and prefs inactive. You can't get back to the prefs window.

This is almost certainly a DUP of one of the unfixed bugs that meta bug 25684, "[crash] modal windows/dialogs are not 100% modal", is dependent on (see especially the ----- Additional Comments From danm@netscape.com 2000-06-14 17:36 -----) or a case of the problem leftover mentioned under ----- Additional Comments From danm@netscape.com 2000-06-29 17:52 ----- Regarding the previous comment, bug 43925, "mozilla freezes when the button "website" is chosen from the themes preferences", was tracking that problem, but as there is no longer a [Website] button, there's no problem now.

*** Bug 61567 has been marked as a duplicate of this bug. ***

Bug 61567 contains steps to reproduce, too.

From Bug 61567, anthonyc@debis.co.za wrote: From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; m18) Gecko/20001129 BuildID: 2000112908 I use an authenticating proxy to connect to the net. If I connect to an external site and then immediately ctrl+alt+del to bring up the NT Security Dialog where one can lock the screen etc and wait a while so that the mozilla proxy authentication dialog would have popped up on the desktop and then return to the desktop the dialog has lost focus but it is still modal. Mozilla is then deadlocked -- I have to kill it from the task manager. Using: NT 4 Service Pack 5 Reproducible: Always Steps to Reproduce: ctrl+alt+del before proxy authentication dialog opens and wait until it would have opened and return to the desktop Actual Results: Proxy authetication dialog is modal and doesn't have focus Expected Results: It should have focus

->moz1.0

*** Bug 53589 has been marked as a duplicate of this bug. ***

Another way to reproduce this, and I've been bitten many times by this today and it's really starting to p*ss me off. 1. In the location field, type in the address of a fair-sized page, such as this bug (http://bugzilla.mozilla.org/show_bug.cgi?id=39841). 2. Press enter to start the page loading. 3. Immediately press Ctrl+L to display the Open Web Location dialog. This should display while Mozilla is still churning away. 4. Let page load. 5. Bash keyboard in frustration as you realize that, once again, Mozilla is hooped. It would be nice to consider this for mozilla0.9 instead of leaving it to the last minute, mozilla1.0.

*** Bug 75021 has been marked as a duplicate of this bug. ***

My initial comment from bug 75021: "This is an intermittent problem, but it shows up often enough. Dialog boxes ranging from those annoying JavaScript popups to alerts from Mozilla about form reloading etc. load BEHIND the active window. Only by collapsing the window am I able to realize why the page won't finish loading. Mozilla Build 2001040608 (and some earlier), OS 9.1." What I failed to mention is that once I've collapsed the window and found the dialog box, by clicking on the dialog box I am able to select an option ("OK" or "Cancel"), go through any following dialog boxes if they exist, and then get back to the main window which finished loading. It doesn't lock Mozilla up permanently. I haven't experienced the bug in a few days, but I don't know that I've visited a site that would produce the bug since then.

*** Bug 75613 has been marked as a duplicate of this bug. ***

*** Bug 72274 has been marked as a duplicate of this bug. ***

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 (you can query for this string to delete spam or retrieve the list of bugs I've moved)

Update target milestone to 'Future' since this missed the 'mozilla1.1beta' train.

Do Firefox on Win use modal windows? I haven't seen. Only on OSX.