Open Bug 39841 Opened 24 years ago Updated 2 years ago

modal window lost focus, now mozilla essentially hung

Categories

(Core :: XUL, defect, P3)

x86
Windows NT
defect

Tracking

()

Future

People

(Reporter: dkarr, Unassigned)

References

Details

(Keywords: hang, helpwanted)

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.
Assignee: asadotzler → trudelle
Status: UNCONFIRMED → NEW
Component: Browser-General → XP Toolkit/Widgets
Ever confirmed: true
QA Contact: jelwell → jrgm
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.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
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.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
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
Assignee: trudelle → danm
Status: REOPENED → NEW
Whiteboard: helpwanted
Target Milestone: --- → 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.
Whiteboard: helpwanted
Keywords: freeze
*** Bug 61567 has been marked as a duplicate of this bug. ***
Bug 61567 contains steps to reproduce, too.
Keywords: freezehang
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
Target Milestone: Future → mozilla1.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.
Depends on: 41813
*** 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)
Target Milestone: mozilla1.0 → mozilla1.0.1
Target Milestone: mozilla1.0.1 → ---
Target Milestone: --- → mozilla1.0.1
Blocks: 140346
Target Milestone: mozilla1.0.1 → mozilla1.1beta
Update target milestone to 'Future' since this missed the 'mozilla1.1beta' train.
Target Milestone: mozilla1.1beta → Future
Assignee: danm.moz → nobody
Do Firefox on Win use modal windows? I haven't seen.
Only on OSX.
Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 5 duplicates.
:enndeakin, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(enndeakin)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(enndeakin)
You need to log in before you can comment on or make changes to this bug.