Found in testing for bug 45108... 1. Right-click a message in Mail/News. 2. Select Move To 3. Allow the sub-menu to open 4. Right-click "Move To" Expected Results: Nothing happens Actual Results: The top-level context menu dismisses and the sub-menu remains. I wonder if this is specific to the mail/news context menu, or if it happens for all multi-level context menus? My guess is the latter. Build: 2001031204 on Win2000 sp1 Can someone check this out on Mac/Linux to see if it's xp? Note: This is _not_ related to the patch I was testing in bug 45108. The build I was using was fresh from mozilla.org.

i've noticed problems with selecting items from submenus of context menus that pose a dialog dismisses only one of the context menus not the whole chain (bug 71219). might be related.

I'd dup this to bug 71219 (or vice versa) if I were you! Bug 7219 describes the same problem with Composer context menu and its Table submenus.

No, don't dupe it. The bugs as they currently are describe different enough circumstances that I suspect they're not the exact same issue. This is a general multi-level context menu bug. I just duplicated this with the Table context menu in composer.

Mike, do you have another example of the sub-menu opening a dialog problem? I'd like to have another place to test this, other than just the insert table context menu mentioned in bug 71219.

that's the only place i know of, i think. why aren't we discussing this in that bug? ;)

i fixed this with my context menu changes last week. probably was the "contextmenu" handler on the popup. fixed.

never mind, this is win32 only.

notes to self: - we're not rolling up the context menu - DealWithPopups correctly finds the click in the parent and does nothing - someone else is causing this window to hide but i can't figure out where that's happening

here's the fix: Index: mozilla/layout/xul/base/src/nsMenuFrame.cpp =================================================================== RCS file: /m/pub/mozilla/layout/xul/base/src/nsMenuFrame.cpp,v retrieving revision 1.172 diff -c -2 -r1.172 nsMenuFrame.cpp *** nsMenuFrame.cpp 2001/03/29 03:32:34 1.172 --- nsMenuFrame.cpp 2001/04/03 18:32:27 *************** *** 359,363 **** aEvent->message == NS_CONTEXTMENU && #endif ! mMenuParent && !IsDisabled()) { // if this menu is a context menu it accepts right-clicks...fire away! // Make sure we cancel default processing of the context menu event so --- 359,363 ---- aEvent->message == NS_CONTEXTMENU && #endif ! mMenuParent && !IsMenu() && !IsDisabled()) { // if this menu is a context menu it accepts right-clicks...fire away! // Make sure we cancel default processing of the context menu event so can someone r/sr?

fixed.

Whoops, my bad. Thanks for catching that, Mike. Verified using 2001040520 Also, bug 71219 is not related to this. That behavior persists.