6058 - Closing the prefs window activates the wrong browser window

Status: VERIFIED DUPLICATE of bug 22658

(Core :: XUL, defect, P1)

Description

[Stephen Beitzel]

If you have multiple browser windows open and then open the prefs window,
then when you close the prefs window the most recently opened browser window
becomes active, not the most recently active browser window.

Steps to reproduce:
1. launch apprunner.exe
2. open a new browser window
3. now, there are two browser windows open. Drag the second one aside.
4. From the first browser, select Preferences from the Edit menu.
5. Close the preferences window by clicking on the close box.
6. Note that the second browser window is activated, not the first.

Comment 1

[leger]

Updating QA Contact from paulmac to cpratt

Comment 2

[shuang (gone)]

Can you check this out or should it be reassigned to someone else?

Comment 3

[german]

Agreed the proper behavior is to switch the active window back to the most
recently active browser window upon concluding prefs.
Sorry to assign more stuff to Don, but you will know best who in your group
works on this for now.

Comment 4

[don]

We can fix this in M7.

Comment 5

[mcmullen]

I don't think this is my bug. I don't do anything with window activation, I just
request a prefs window, and tell it to close itself. Maybe danm can enlighten us?

Changing component from prefs to XP Toolkit/Widgets and reassigning to danm.

Comment 6

[Dan M]

Disagreeing with Don's statement that "we" can fix this in M7.  It's annoying, but it's not
breaking anything.  Postponing.

Comment 7

[Peter Trudelle]

mass-moving all m12 bugs to m13

Comment 8

[Matthew T (active 1999-2002)]

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

Comment 9

[sairuh (rarely reading bugmail)]

spam: reassigning QAcontact to me, and added matt and don to cc list...

Comment 10

[Matthew T (active 1999-2002)]

This looks fixed to me -- build 2000011314/Win98.
[also removing spurious dependencies]

Comment 11

[kevin arnold]

Okay, this might sound strange, but I see a similar thing happening on my
machine right now.

I go to preferences/Mail & Newsgroups and set the color for quoted text.  When I
click the OK button to close the preferences, the active browser window drops to
the back (bringing the window immediately behind it to the front).

(Build 2000030116/Win98)

Comment 12

[Dan M]

I see that, too. It's fixed in the general case (where we have a parent window), 
but the act of making a selection in a color popup in a modal dialog confuses 
things so the modal window's parent gets sent to the background when the modal 
window itself is closed. Har. That's just silly.

Comment 13

[Sean Richardson]

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

Comment 14

[Peter Trudelle]

Mass moving M17 bugs to M18

Comment 15

[sairuh (rarely reading bugmail)]

->jrgm.

Comment 16

[Matthew T (active 1999-2002)]

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

Comment 17

[Bill Law]

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

Comment 18

[Peter Trudelle]

mass-moving all bugs to m21 that are not dofood+, or nsbeta2+

Comment 19

[Sean Richardson]

Adding correctness and mostfreq keywords (look at the DUPs for more DUPs
if you have any doubt). Gerv, use your judgement - most of those DUPs were
filed back when closing the prefs dialog *always* activated the wrong window.

Quoting from bug 22658, "Closing some dialogs activates the wrong window::
 > ------- Additional Comments From Matthew Thomas 2000-02-10 18:05 ------ ...
 > * Preferences dialog: fixed, *except* where you open a dialog from within
 >   the prefs window, and then close it. Examples:
 >   - `Choose File' in Navigator pane
 >   - `View Stored Cookies' in Advanced > Cookies pane.
 >   When the prefs dialog is eventually closed, the Mozilla window underneath
 >   disappears behind whatever window was just under it. I'm pretty sure this 
 >   is a regression.

Testing with 2000-08-01-04-M17 on WinNT, the behaviour is still exactly as
Matthew described it. Sairuh, isn't there another bug about problems with
non-modal windows over modal windows causing problems?

Comment 20

[sairuh (rarely reading bugmail)]

Sean, y'mean bug 25684?

Comment 21

[Gervase Markham [:gerv]]

I've you've nominated it, Sean, that's good enough for me :-)

Gerv

Comment 22

[Jason Eager]

Why is this so hard to fix?

Comment 23

[Dan M]

Go for it.

Comment 24

[Dan M]

*** This bug has been marked as a duplicate of 22658 ***

Comment 25

[Joseph Elwell]

marking verified. dialog parent windows problem.