78364 - Mac: Pref window sometimes loses focus -> Mozilla hangs

Status: VERIFIED FIXED

(SeaMonkey :: Preferences, defect)

Description

[gsa]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.8.1+) Gecko/20010430
BuildID:    2001043014

when i choose preferences from the edit menu the preferences window pops up
behind the browser window, clicking on the preferences window doesn't make it
appear in front of the browser window. the browser and command menu become
unclickable, i have to force quit Mozilla

Reproducible: Sometimes
Steps to Reproduce:
1. start up mozilla
2. select preferences in the edit menu
3. preferences window will appear behind the browser window

Actual Results:  preferences window appeared behind the browser window

Expected Results:  preferences window should have appeared in front of the
browser window

Comment 1

[sairuh (rarely reading bugmail)]

hrm, i cannot repro this using 2001.05.02.09 comm bits on mac os 9.0x. danm,
mpt, do either of you see this?

Comment 2

[gsa]

preferences window appearing behind browser window happens after i first run
Mozilla and try to edit preferences for the first time.

Comment 3

[Matthew T (active 1999-2002)]

Yes, I've seen this occasionally. Here's a simple testcase.

Build: 2001050314, Mac OS 9.1
*   Start Mozilla.
*   Close all open windows.
*   Choose `Edit' > `Preferences ...'.
*   Try to do anything.

What happens:
*   The Preferences window appears inactive.
*   You can't do anything in Mozilla.

I've also seen this happen occasionally when browser windows are open, as gsa 
describes, but I can't reliably reproduce it.

Workaround:
*   Switch to another application, then switch back to Mozilla.

Comment 4

[Matthew T (active 1999-2002)]

This also happens with the Address Book. It *may* be related to bug 74499.

Comment 5

[Chris McAfee]

over to pchen for a look

Comment 6

[sairuh (rarely reading bugmail)]

confirming per mpt's and reporter's comments.

Comment 7

[gsa]

still happening in mozilla 0.9 release build id: 2001050518

Comment 8

[Dan M]

  Thanks for the reliable steps to reproduce, Matthew.
  HiddenWindow recently became visible (though offscreen) on the Mac. For some 
reason the Incredible Visible Hidden Window is getting activate events from the 
OS, and insisting on being in front of the preferences window. More investigation 
is wanted.

Comment 9

[Dan M]

This is probably caused by an interaction between some old code in GlobalWindow 
and a recent change to make HiddenWindow visible. That latter bit was because of 
a bug in OSX (see bug 70388).

The former bit is a curious chunk of code in nsGlobalWindow::Deactivate which 
ensures the window is visible. While becoming visible (which it already was), 
HiddenWindow is brought to the top. Especially since this is done to all windows, 
you'd think this would cause all sorts of z-ordering problems. And in fact my 
entire Mac build is much happier with that code removed. Lately I've been 
noticing a bunch of bad problems with windows refusing to take activation, many 
or all of which are corrected by removing that code.

I don't understand why it would be important or useful to make a window visible 
during its deactivation. It was added as part of rev 1.222, which was all about a 
seemingly unrelated topic. It looks like yet another instance of an inexplicable 
tbogard drive-by change. (Though to be fair, it did take us this long to notice a 
problem.)

Ask me, I think we can strip that code out.

Index: mozilla/dom/src/base/nsGlobalWindow.cpp
===================================================================
RCS file: /cvsroot/mozilla/dom/src/base/nsGlobalWindow.cpp,v
retrieving revision 1.397
diff -u -2 -r1.397 nsGlobalWindow.cpp
--- nsGlobalWindow.cpp	2001/05/08 19:43:47	1.397
+++ nsGlobalWindow.cpp	2001/05/09 04:33:55
@@ -2826,9 +2826,4 @@
 NS_IMETHODIMP GlobalWindowImpl::Deactivate()
 {
-  nsCOMPtr<nsIBaseWindow> treeOwnerAsWin;
-  GetTreeOwner(getter_AddRefs(treeOwnerAsWin));
-  if (treeOwnerAsWin)
-    treeOwnerAsWin->SetVisibility(PR_TRUE);
-
   nsCOMPtr<nsIPresShell> presShell;
   mDocShell->GetPresShell(getter_AddRefs(presShell));

Comment 10

[Adam]

I believe this problem also occured in earlier builds, way before Pinkerton 
checked in the Mac OS X fix, so I don't think that's the cause. His fix might 
have made the problem worse, but I think it's been happening off and on 
for quite some time.

Comment 11

[Dan M]

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

Comment 12

[Dan M]

.

Comment 13

[Dan M]

nsGlobalWindowImpl::Deactivate no longer sets visibility(true)

Comment 14

[sairuh (rarely reading bugmail)]

drat, cannot vrfy...methinks am being blocked by bug 74499 if i go by mpt's
steps...nor do i get into the state that gsa originally reported. adding
verifyme.

Comment 15

[Guillaume Filion]

Verified on build 2001-05-18 11 on Mac OS 8.6.