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)
Tracking
()
VERIFIED
FIXED
mozilla0.8.1
People
(Reporter: c, Assigned: mikepinkerton)
References
Details
Attachments
(3 files)
2.53 KB,
patch
|
Details | Diff | Splinter Review | |
2.69 KB,
patch
|
Details | Diff | Splinter Review | |
2.68 KB,
patch
|
Details | Diff | Splinter Review |
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
Comment 1•24 years ago
|
||
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
Assignee | ||
Updated•24 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → M21
Assignee | ||
Comment 2•24 years ago
|
||
works for me under Win2k. will resovle as WFM unless someone else can duplicate.
Target Milestone: M21 → ---
Comment 3•24 years ago
|
||
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
Reporter | ||
Comment 4•24 years ago
|
||
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.
Assignee | ||
Comment 5•24 years ago
|
||
hrm, i'll nominate for beta3, but chances are good this will get futured.
Keywords: nsbeta3
Target Milestone: --- → M22
Reporter | ||
Comment 6•24 years ago
|
||
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.
Comment 7•24 years ago
|
||
nsbeta3-, unlikely scenario, only freezes on original Win95
Whiteboard: nsbeta3-
Assignee | ||
Updated•24 years ago
|
Target Milestone: M22 → Future
Comment 8•24 years ago
|
||
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.
Assignee | ||
Updated•24 years ago
|
Target Milestone: Future → mozilla1.0
Comment 10•24 years ago
|
||
This one has me stumped.
Assignee | ||
Updated•24 years ago
|
Target Milestone: mozilla1.0 → mozilla0.9
Comment 11•24 years ago
|
||
I wonder if this is related to bug 50798, where the menu may be grabbing focus?
Comment 12•24 years ago
|
||
*** Bug 65913 has been marked as a duplicate of this bug. ***
Assignee | ||
Updated•24 years ago
|
Comment 13•23 years ago
|
||
Based on bug 45202, this sounds like it could be more than just Windows. I'll start by looking in the XP code, then.
Comment 14•23 years ago
|
||
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.
Comment 15•23 years ago
|
||
Comment 16•23 years ago
|
||
Dean, you sexy menu go, you!
Comment 17•23 years ago
|
||
Comment 18•23 years ago
|
||
> sexy menu go,
er, god
Assignee | ||
Comment 19•23 years ago
|
||
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?
Comment 20•23 years ago
|
||
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.
Comment 21•23 years ago
|
||
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.
Comment 22•23 years ago
|
||
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.
Comment 23•23 years ago
|
||
Assignee | ||
Comment 24•23 years ago
|
||
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.
Comment 25•23 years ago
|
||
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?
Comment 26•23 years ago
|
||
_Really_ cc:ing Hyatt for an sr=. Hyatt, please check out my previous comment to see the testing that I've done on this.
Assignee | ||
Comment 27•23 years ago
|
||
dean: thanks for being so thorough. no, i'm not aware of the issue with context menus you mention. file a new bug.
Comment 28•23 years ago
|
||
Done. Bug 71795 assigned to... you! Also, I meant bug 39276 above, not bug 39726.
Comment 29•23 years ago
|
||
Re point 12: Windows 95 context menus accept right-clicks the same as left-clicks.
Assignee | ||
Comment 30•23 years ago
|
||
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
Comment 31•23 years ago
|
||
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.
Assignee | ||
Comment 32•23 years ago
|
||
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.
Comment 33•23 years ago
|
||
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.
Assignee | ||
Comment 34•23 years ago
|
||
no, i see this w/ no menus open, just clicking the minimize button in the window title bar.
Comment 35•23 years ago
|
||
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.
Assignee | ||
Comment 36•23 years ago
|
||
fixed.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
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.
Description
•