71795 - Mail/News: Right-click of Move To in context menu leaves sub-menu stranded

Status: VERIFIED FIXED

(Core :: XUL, defect)

Description

[:deanis74]

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.

Comment 1

[Mike Pinkerton (not reading bugmail)]

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.

Comment 2

[Charles Manske]

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.

Comment 3

[:deanis74]

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.

Comment 4

[:deanis74]

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.

Comment 5

[Mike Pinkerton (not reading bugmail)]

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

Comment 6

[Mike Pinkerton (not reading bugmail)]

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

fixed.

Comment 7

[Mike Pinkerton (not reading bugmail)]

never mind, this is win32 only.

Comment 8

[Mike Pinkerton (not reading bugmail)]

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

Comment 9

[Mike Pinkerton (not reading bugmail)]

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?

Comment 10

[Mike Pinkerton (not reading bugmail)]

fixed.

Comment 11

[:deanis74]

Whoops, my bad.  Thanks for catching that, Mike.  Verified using 2001040520

Also, bug 71219 is not related to this.  That behavior persists.