Closed Bug 22658 Opened 25 years ago Closed 24 years ago

stacked dependent dialogs activate the wrong window when closed

Categories

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

Product:
Core Graveyard
Component:
Embedding: APIs
Platform:
x86
Windows 98
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: mpt, Assigned: danm.moz)

References

Details

(Keywords: platform-parity, Whiteboard: [nsbeta3+]) 

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.
Blocks: 6058, 18455
Status: NEW → ASSIGNED
Target Milestone: M15
No longer blocks: 6058
No longer blocks: 18455
spam: clearing dependencies -- I made a mess, and I'm really, really sorry. Will
all be fixed in two minutes.
Depends on: 6058, 18455
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
Keywords: pp
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.
Summary: [PP] Closing some dialogs activates the wrong window → Closing some dialogs activates the wrong window
Moving all UE/UI bugs to new component: User Interface: Design Feedback
UE/UI component will be deleted.
Component: UE/UI → User Interface: Design Feedback
*** Bug 28644 has been marked as a duplicate of this bug. ***
*** Bug 29988 has been marked as a duplicate of this bug. ***
*** Bug 30701 has been marked as a duplicate of this bug. ***
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

*** Bug 30561 has been marked as a duplicate of this bug. ***
No longer depends on: 6058
No longer depends on: 18455
Blocks: 6058, 18455
Depends on: 27048
On 2000032018, nb1b, on Win95, I am getting the behavior described by
mpt@mailandnews.com on 02/11. Previously what he listed as being fixed was still
broken, but it's working fine now.


*** Bug 32578 has been marked as a duplicate of this bug. ***
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.
Blocks: 7862
Target Milestone: M15 → M16
Mass-moving all M16 non-feature bugs to M17, which we still consider to be 
part of beta2
Target Milestone: M16 → M17
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

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

QA Assigning non-confidential New/Assigned User Interface: Design Feedback bugs 
to Matthew Thomas (mpt@mailandnews.com).

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 elig@netscape.com.)
QA Contact: elig → mpt
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?

moving to m18
Target Milestone: M17 → M18
The Find on this Page dialog works perfectly!

mass-moving all bugs to m21 that are not dofood+, or nsbeta2+
Target Milestone: M18 → M21
No longer depends on: 27048
*** Bug 43445 has been marked as a duplicate of this bug. ***
Target Milestone: M21 → Future
*** Bug 48298 has been marked as a duplicate of this bug. ***
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".
Keywords: nsbeta3
Target Milestone: Future → ---
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
Whiteboard: [nsbeta3-]
Target Milestone: --- → Future
Blocks: 46427
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.
Whiteboard: [nsbeta3-]
Target Milestone: Future → ---
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.
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.
Keywords: 4xp, correctness, mostfreq
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.
Whiteboard: [need info]
nsbeta3+, p3 for M18
Whiteboard: [need info] → [nsbeta3+]
Target Milestone: --- → M18
*** Bug 50486 has been marked as a duplicate of this bug. ***
Whiteboard: [nsbeta3+] → [nsbeta3+] got it figured out. tentative solution in hand.
*** Bug 18455 has been marked as a duplicate of this bug. ***
  (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.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Summary: Closing some dialogs activates the wrong window → stacked dependent dialogs activate the wrong window when closed
Whiteboard: [nsbeta3+] got it figured out. tentative solution in hand. → [nsbeta3+]
*** Bug 6058 has been marked as a duplicate of this bug. ***
*** Bug 42084 has been marked as a duplicate of this bug. ***
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...
QA Contact: mpt → zach
Note the fix for this bug was partially backed out. See bug 54936.

*** Bug 87504 has been marked as a duplicate of this bug. ***
How do other Windows applications deal with this bug?
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.

Marking VERIFIED FIXED on the above comments and test conducted with build
2001092703 on WindowsME
Status: RESOLVED → VERIFIED
This still happens every time I get "The text you entered was not found" on top
of the Find dialog.
Component: User Interface Design → Browser-General
*** Bug 129383 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
Component: General → Embedding: APIs
Product: SeaMonkey → Core
QA Contact: zach → apis
Target Milestone: M18 → ---
Version: Trunk → unspecified
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.