22658 - stacked dependent dialogs activate the wrong window when closed

Status: VERIFIED FIXED

(Core Graveyard :: Embedding: APIs, defect, P3)

Description

[Matthew T (active 1999-2002)]

BUILD:

    1999122308/Win98 (and many, many builds before that)

TO REPRODUCE:

    1.  Open a non-modal Mozilla window (e.g. browser or mail window).

    2.  Give another window focus -- preferably one from another app, to avoid
        confusion about which window is which.

    3.  Give the Mozilla window focus.

    4.  Open any of the following dialogs:
        * the open location dialog (`File' > `Open Web Location ...', in a
          Navigator window)
        * the Preferences dialog (`Edit' > `Preferences ...', in any window)
        * the Wallet key dialog (by selecting `Tasks' > `My Wallet' > `Wallet
          Contents ...' for the first time in this installation, or just after
          having deleted C:\Users50\).
        Bug 18455 reports that the Account Setup window also suffers from this
        bug, but it seems ok to me right now.

    5.  Click `Cancel' in the dialog.

WHAT SHOULD HAPPEN

    You should be returned to the window from which you opened the dialog.

WHAT ACTUALLY HAPPENS

    The next (non-minimized) window *below* the window from which you opened the
    dialog is activated -- even if it is not a Mozilla window.

NOTES

    This bug generalizes bug 6058, bug 18455, and bug 20999, with other
    instances, and with formal steps to reproduce. Each of those bugs are
    instances of this bug, and I'm guessing it's the same XUL/JS problem in each
    one.

Assigning to danm, because he already owns two of these.

Comment 1

[Matthew T (active 1999-2002)]

spam: clearing dependencies -- I made a mess, and I'm really, really sorry. Will
all be fixed in two minutes.

Comment 2

[Sean Richardson]

Hmm. this seems to be working correctly now for the Prefs dialog, but not for
the `Tasks' > `My Wallet' > `Wallet Contents ...' dialog. 

Tested with: 2000-01-22-08-M14 nightly binary on Windows NT 4.0sp3

Comment 3

[Matthew T (active 1999-2002)]

Build 2000021014, Win98.

* Open location dialog: fixed.

* 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.

* Wallet Contents: seems fixed, but verification blocked by the fact that the
  `Tasks' menu stays open (!) while the wallet contents dialog is open.

Comment 4

[leger]

Moving all UE/UI bugs to new component: User Interface: Design Feedback
UE/UI component will be deleted.

Comment 5

[Dan M]

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

Comment 6

[Asa Dotzler [:asa]]

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

Comment 7

[Jerry Baker]

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

Comment 8

[Jonas Nagel]

Whatever windows you listed as fixed there still is broken for me on M15 on
Win2000. To give a few examples:

- Preferences => Cancel => still switches to the previous window
- File => Open Web Location... => same

Comment 9

[Ryan Massie]

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

Comment 10

[Brad Nixon]

On 2000032018, nb1b, on Win95, I am getting the behavior described by
[e-mail] on 02/11. Previously what he listed as being fixed was still
broken, but it's working fine now.

Comment 11

[rogerl (gone)]

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

Comment 12

[Sean Richardson]

Not sure why bug 7862, "When prefs window is left, focus switches to other app",
is still around paralleling bug 6058, "Closing the prefs window activates the 
wrong browser window", but adding it to the dependencies so that it does not
get missed when this bug gets verified.

Comment 13

[Peter Trudelle]

Mass-moving all M16 non-feature bugs to M17, which we still consider to be 
part of beta2

Comment 14

[[e-mail]]

Java suffered from the same bug. I think this is because Microsoft assumes that
everyone will use DialogBox to create modal dialogs and doesn't document modal
dialog activation and deactivation. See also:
http://developer.java.sun.com/developer/bugParade/bugs/4065506.html

Comment 15

[[e-mail]]

I'd like to mention a bug which may be related to this bug.
If two Mozilla windows are open, e.g. browser and mail,
and then a modal window, e.g. Account Preferences, is opened,
it is impossible to activate the browser window over the modal window.
Build: 2000041210/Win95

Comment 16

[Eli Goldberg]

QA Assigning non-confidential New/Assigned User Interface: Design Feedback bugs 
to Matthew Thomas ([e-mail]).

Matthew Thomas is now the QA owner for the User Interface: Design Feedback 
component. (Bugs that involve UI issues in the Netscape-branded Mozilla browser 
should continue be QA assigned to [e-mail].)

Comment 17

[Matthew T (active 1999-2002)]

I can't see how this bug could possibly be dependent on bug 27048, `[Activation] 
need http clients to implement nsIHTTPEventSink', a Networking bug. danm, you put 
that dependency there -- why?

Comment 18

[Peter Trudelle]

moving to m18

Comment 19

[[e-mail]]

The Find on this Page dialog works perfectly!

Comment 20

[Peter Trudelle]

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

Comment 21

[Asa Dotzler [:asa]]

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

Comment 22

[saari (gone)]

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

Comment 23

[Charles Manske]

Since 43445 was dup'd to this, I'm removing "future" target and nominating this 
for nsbeta3.
Maintaining proper window parenting is very important and very confusing to
user to have windows "disappear".

Comment 24

[Peter Trudelle]

I agree that it is confusing, but we cannot commit to fixing this for 6.0. If
you can come up with a crash or data loss scenarior for this, we'll reconsider.
 cc jrgm, nsbeta3-, ->future

Comment 25

[Charles Manske]

Peter: We are getting lots of complaints using dialogs in Composer -- this is
our main UI mechanism. When you have many windows active, after using a dialog 
in a composer window, you loose that window when dialog is dismissed. This is
not acceptable! We have had many bug submissions, now duped to 46427. That bug
was deemed nsbeta3+. 
As I stated before, maintaining focus on a user's active window is a fundamental
aspect of any program! You may not loose data, but you loose your window!
Removing nsbeta- for reconsideration.

Comment 26

[Charles Manske]

I still believe this should be fixed, but I've found a crude workaround:
In the JS to lauch a dialog, usually something like this:
 window.openDialog("chrome://editor/content/EdColorProps.xul","_blank", 
     "chrome,close,titlebar,modal", "");
you should add a statement to return focus to your window like this:
 window._content.focus();
Using this, there is ugly flashing as the wrong window gets focus initially,
but at least it is pulled back to the correct window.

Comment 27

[Sean Richardson]

Adding "correctness" and "4xp" keywords as the current behaviour violates the
expectations of *all* users. I'm not even sure it could be said that this
is less of a problem for users who only surf and rarely use dialogs: they
will run into this problem more rarely, but it will also be more unexpected.

Also nominating for "mostfreq" -- it's already earned ...
Bug 6058, "Closing the prefs window activates the wrong browser window", 
which this bug depends on, is already a Most Frequent bug, but the problem
extends to many other parts of the App.

The workaround would IMHO be better than nothing.

In regards to the focus flashing, a search for the (unfortunately unidentified) 
code change that fixed bug 29851, "clicking on an item in a context menu causes 
the window to de-activate for a split second (title bar)", may (or may not)
be instructive.

Comment 28

[Peter Trudelle]

need info: Charlie, will the JS focus you describe be sufficient to hack arouind
this in the bugs this blocks? With the workaround, I'm even less inclined to
commit to a fix, but I'd like to see the flashing.

Comment 29

[Peter Trudelle]

nsbeta3+, p3 for M18

Comment 30

[Peter Trudelle]

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

Comment 31

[Dan M]

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

Comment 32

[Dan M]

  (I changed the summary to reflect what I believe is the only currently 
remaining bug of this type: the only problem I know of is that any situation 
where a dependent/modal dialog itself creates another window (dependent or not 
(and by "dependent" I mean what Windows calls "owned")), then when the windows 
are closed, a surprising window is always brought to the front.) Stacked modal 
dialogs happen in a disappointingly large number of different places in Mozilla, 
so this bug has lots of duplicates.
  This is a Windows bug. I've demonstrated that by duplicating the circumstances 
and the symptoms in a very simple, straightforward Windows app that doesn't even 
involve MFC and certainly doesn't involve Mozilla.
  I've hacked in a workaround. It's not nearly as pretty or self-contained as I'd 
have liked, but I found a place where I could bring a window's owner to the front 
before closing that seems to make things all better. I'm using Windows 2000, 
mind.
  Calling it fixed.

Comment 33

[Dan M]

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

Comment 34

[Dan M]

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

Comment 35

[Zach Lipton [:zach]]

Chaning the qa contact on these bugs to me. MPT will be moving to the 
owner of this component shortly. I would like to thank him for all his hard 
work as he moves roles in mozilla.org...Yada, Yada, Yada...

Comment 36

[Dan M]

Note the fix for this bug was partially backed out. See bug 54936.

Comment 37

[Dan M]

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

Comment 38

[Jesse Ruderman]

How do other Windows applications deal with this bug?

Comment 39

[Dan M]

They just let it slide. Ask Saari about it. He found some Windows apps that had 
the situation and the bug. (I think he made it happen in Photoshop; maybe 
others.) That's why we feel confident labeling this an OS bug: you can see it 
happening in other apps and in a little test app I wrote. Oh and I found some 
bare mention of it in Microsoft's knowledge base.

Comment 40

[Jacek Piskozub]

Marking VERIFIED FIXED on the above comments and test conducted with build
2001092703 on WindowsME

Comment 41

[Jesse Ruderman]

This still happens every time I get "The text you entered was not found" on top
of the Find dialog.

Comment 42

[Dan M]

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