Closed Bug 45108 Opened 24 years ago Closed 23 years ago

open menus don't disappear on "minimize all windows" in Win NT

Categories

(Core :: XUL, defect, P3)

x86
Windows NT
defect

Tracking

()

VERIFIED FIXED
mozilla0.8.1

People

(Reporter: c, Assigned: mikepinkerton)

References

Details

Attachments

(3 files)

Not sure if this is a bug in mozilla or in Win NT
(I use mozilla M16 with NT4, SP3).

Steps to reproduce:
1. Open a menu in mozilla (menubar as well as context menu)
2. Move the cursor down the some entry
3. Press <win-key>/<m>

Expected behaviour:
Mozilla-windows including the open menu disappears

Actual behaviour:
The open menu does not disappear

May be related to bug 22427 and/or bug 30488
this is indeed a problem.  Confirmed with 071108 mozilla build on NT .  over to
Toolkit.
Assignee: asa → pinkerton
Status: UNCONFIRMED → NEW
Component: Browser-General → XP Toolkit/Widgets: Menus
Ever confirmed: true
QA Contact: doronr → jrgm
Status: NEW → ASSIGNED
Target Milestone: --- → M21
works for me under Win2k. will resovle as WFM unless someone else can duplicate.
Target Milestone: M21 → ---
I can reproduce this on win95 and win2k. Note that you must be mouseover the 
context menu when you press winkey-M (i.e., a menuitem is in :hover style).

With one browser window open, selecting any of the options in the context menu 
will execute the command and bring the parent window back onto the screen.

However (uggh), with a browser window and a mailnews window open (when 
winkey-M is pressed, and a context menu up) will *freeze* win95 [until you 
ctrl-alt-del and kill mozilla]. (win2k does not freeze). 

So, no longer trivial, but it is an edge case.
Severity: trivial → normal
Yes, you must be mouseover the context menu or a menu of menubar when you
press winkey-m to reproduce this bug on Win NT 4, too.

Additional observations (still with M16, sorry about that, hoping they will
be useful nevertheless ...):

NT 4 normally does not freeze, but if the Edit menu is open when minimizing
and you select "Preferences" after that, Mozilla gets very confused as soon
as you press winkey-shift-m to get back the minimized windows.
You can't close any window or do something useful, so you have to kill it.

If you have a open Preferences window, this window and it's parent window
don't disappear on winkey-m, too.

After pressing winkey-m with a mozilla menu left on the screen, most commands
are executed if you select them, but submenus don't appear.
hrm, i'll nominate for beta3, but chances are good this will get futured.
Keywords: nsbeta3
Target Milestone: --- → M22
The freeze in win95 observed by jrgm and the problems with the Preferences
window may be related to bug 39841. I've added a comment there.
nsbeta3-, unlikely scenario, only freezes on original Win95
Whiteboard: nsbeta3-
Target Milestone: M22 → Future
Blocks: 39276
Andreas M. "Clarence" Schneider wrote:
> If you have a open Preferences window, this window and it's parent window
> don't disappear on winkey-m, too.

This is normal Windows behaviour, dialogs and their parents are not affected.
*** Bug 53926 has been marked as a duplicate of this bug. ***
Target Milestone: Future → mozilla1.0
Blocks: 45202
This one has me stumped.
Target Milestone: mozilla1.0 → mozilla0.9
I wonder if this is related to bug 50798, where the menu may be grabbing focus?
Blocks: 63527
*** Bug 65913 has been marked as a duplicate of this bug. ***
Keywords: nsbeta3
Whiteboard: nsbeta3-
Target Milestone: mozilla0.9 → mozilla0.9.1
Blocks: 68889
Based on bug 45202, this sounds like it could be more than just Windows.  I'll 
start by looking in the XP code, then.
Yay, progress!  I finally see what's going on here.  In nsWindow.cpp, we're 
calling EventIsInsideWindow() for WM_ACTIVATE, which can be either for window 
activation or de-activation.  The problem is, we don't care if the event is 
inside the window or not for this message.  We should always rollup.

I'm going to attach a possible patch in a few minutes.  It's one possible way of 
doing it, and I like doing it this way because it centralizes the WM_ACTIVATE 
check into one place.
Dean, you sexy menu go, you!
> sexy menu go,

er, god 
nitpick, but you should leave

+      PRBool rollup;
+      rollup = !nsWindow::EventIsInsideWindow(inMsg, (nsWindow*)gRollupWidget);

on one line as it was in the previous version:

PRBool rollup = !nsWindow::EventIsInsideWindow(inMsg, (nsWindow*)gRollupWidget);

what other cases do we get WM_ACTIVATE for popups? Could this cause us grief with 
hierarchical submenus when the mouse leaves them, or when using x-mouse and 
mousing back into a parent menu? 
Oh yeah, I forgot about that.  I used to have an "if" there, but I took it out.
 As for the x-mouse, I'll try my patch for the x-mouse bug later tonight and see
if it works together with this.

As for general WM_ACTIVATE and popup issues, can you think of any time when we'd
want to track where the mouse was?  We still do the normal EventIsInsideWindow
for WM_MOUSEACTIVATE, so I think we'll be OK.
X-mouse _shouldn't_ matter because that activates the window through a 
WM_MOUSEACTIVATE message.  But, as I said, I'll this out in a little while.
I'm not seeing any problem with this in conjunction with my x-mouse patch (bug 
50798).  Hierarchical menus still work fine as well, with or without x-mouse.
make sure you try context menus in mail, especially the "move to" hierarchical 
menu. just make sure it behaves. make sure that alt keys and menus still work as 
well as arrowing around in menus and between menus on the menu bar. just being 
anal, I don't want to see anything regress.

once you check all that, r=pink.
No problem Mike.  Here's a summary of what I've tested.  Any x-mouse-related 
items include the patch for bug 50798.  All items on this list are independent 
of all other items.

1. Open a context menu, highlight an item, then press Window+M.  Menu
   dismisses and window minimizes.  This is the expected behavior.
2. Open a context menu, don't highlight any item, then press Window+M.
   Menu dismisses and window minimizes.  Expected behavior.
3. Repeat items 1 and 2 with X-mouse enabled.  Both work as expected.
4. Drop down a menu from the main menu, highlight a menu, then press
   Window+M.  Menu dismisses and window minimizes.  Expected behavior.
5. Drop down a menu from the main menu, don't highlight, then Win+M.
   Menu dismisses and window minimizes.  Expected behavior.
6. Repeat items 4 and 5 with X-mouse enabled.  Both work as expected.
7. Type in a partial address that causes auto-complete to drop down.
   Win+M.  Menu dismisses and window minimizes.  Expected behavior.
8. Repeat step 7 with X-mouse.  Works as expected.
9. Tested menulists using the attachment in bug 45202, with and
   without x-mouse enabled.  Everything works as expected.
10. Ensure that auto-complete works as expected.  It does.
11. Ensure that main menus and context menus work as expected.  They
    do.
12. Play around extensively with the Copy To and Move To context menus
    in mail, with X-mouse off and on.  I found a problem with opening
    up the Move To sub-menu, then right-clicking on the Move To item
    itself.  The first-level context menu dismisses and the sub-menu
    remains.  .... And you know what?  It's there in today's build
    that I just downloaded.  So I can say that the mail/news context
    menus work at least as well as they do in today's build.
13. Press Alt, F to activate the File menu.  File menu opens.  Expected
    behavior.
14. Press Alt+F to activate the File menu.  File menu opens.  Expected
    behavior.
15. Press Ctrl+F.  Search dialog opens.  Expected behavior.
16. Open up the File menu.  Mouse over a menu item.  Press the right
    arrow.  Edit menu opens.  Expected behavior.
17. Open up the File menu.  Don't highlight any menu item.  Press the
    right arrow.  Edit menu opens.  Expected behavior.

Note that I've also run through the test cases in bug 63527, bug 68889, bug 
39726, bug 45202, bug 37992, and bug 31601.  All of those issues are resolved 
with this patch.

Assuming this is sufficient testing for Mike, cc:ing Hyatt for an sr=.

ps. Anyone know if there's a bug filed for what I described in point 12?
Blocks: 31601, 37992
_Really_ cc:ing Hyatt for an sr=.  Hyatt, please check out my previous comment 
to see the testing that I've done on this.
dean: thanks for being so thorough. no, i'm not aware of the issue with context 
menus you mention. file a new bug.
Done.  Bug 71795 assigned to... you!

Also, I meant bug 39276 above, not bug 39726.
Re point 12: Windows 95 context menus accept right-clicks the same as left-clicks.
hyatt sez as long as you've beaten the heck out of it, let's take it. it's easy 
to back out if need be. sr=hyatt.

i'll try to land this today.
Target Milestone: mozilla0.9.1 → mozilla0.8.1
Please note that the problem of not being able to dismiss a context menu with
escape is present in Today's build (2001031304).  I'll file a bug soon if
there's not already one filed.
i tried both this patch and the x-mouse patch and i've noticed that when i 
minimize the window and bring it back to normal, it doesn't repaint correctly. 
rebuilding the tip to see if that's the case there as well, but heads up dean! 
this might be a regression.
Minimize the window, meaning do a minimize-all while a menu item is selected?  I
noticed that too, sometimes, and apparently forgot to mention it.  It's hard to
be a regression, though, if it's functionality that we never had before.
no, i see this w/ no menus open, just clicking the minimize button in the window 
title bar.
Aoooo??  Hmmm...  How could that be related?  All I did was mess with the
DealWithPopups() function.  Minimizing a window should be in the
WM_WINDOWPOSCHANGING processing, or something like that.
fixed.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Verified.
Status: RESOLVED → VERIFIED
Component: XP Toolkit/Widgets: Menus → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: