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.

works for me under Win2k. will resovle as WFM unless someone else can duplicate.

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.

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.

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

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

This one has me stumped.

I wonder if this is related to bug 50798, where the menu may be grabbing focus?

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

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?

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

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.

Verified.