Closed Bug 31727 Opened 24 years ago Closed 24 years ago

right click doesn't work within context submenus/folders in thread pane

Categories

(Core :: XUL, defect, P3)

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: bugzilla, Assigned: mikepinkerton)

Details

(Whiteboard: [nsbeta2-])

Attachments

(1 file)

found this while using opt commercial bits on both linux
[2000.03.13.03-m15-nb1b] and wiNT [2000.03.10.09]. i have Mail setup so that it
uses IMAP.

to repro:
1. open the 3-pane Mail window.
2. select a message from the thread pane (so that it's highlighted).
3. right-mouse click the highlighted message. a context menu should appear.
4. from this context menu, select Move To > [your userid] > [some folder] *using
the right mouse button* to try move the message into that folder.

result: nothing happens, ie, the message isn't moved into that folder. need to
use the left mouse button to do this.

expected: should be able to move the message into the folder using the right
mouse button. context menu selection via the right mouse button used to be a
problem within the browser, but was fixed a couple of weeks ago (bug, 17159).
Mail should be consistent with this as well.

note that the following tasks *do* work:
* thread pane: selecting Forward, Reply To Sender, or any of the top-level
context menu items with the right or left mouse buttons does work.
* folders pane: selecting context menu items with the right or left mouse
buttons also works fine.
ahhhh, i see what's going on now. this is my bug, not phil's (sorry for the 
confusion). 

what is happening is that the submenu is not inheriting the "context menu-ness" 
of its parent when it is created so the right-click code doesn't know it's a 
context menu.

cc'ing dean as he will be interested in this as well.
Assignee: phil → pinkerton
"cc'ing dean as he will be interested in this as well."

Interested?  Well, there's an understatement if ever I've heard one (please not
the intense sarcasm here).  I thought that this might be the case with my bug,
but when I asked for help in 17159, nobody came through with a multi-level
context menu.  The fix shouldn't be too tough, but I'll need a few days to get
to it.

Setting QA Contact to nbaca, adding lchiang to Cc: list.
QA Contact: lchiang → nbaca
m16

Status: NEW → ASSIGNED
Component: Front End → XP Toolkit/Widgets: Menus
Product: MailNews → Browser
Target Milestone: M16
Well, that's interesting.  These submenus don't seem to call 
nsPopupSetFrame::CreatePopup themselves, so I'm obviously looking in the wrong 
place.  Off I go to search somewhere else...
moving all defects not directly related to P0 beta2 features off to M18.
Target Milestone: M16 → M18
OK, I'm stuck on this one.  I can't even grab where the submenus are created 
(nsPopupSetFrame, etc.).  If I could find that, I could probably resolve this.
Well, I can get this to work the first time that the submenu opens, but after 
that things screw up.  It's related to the fact that the first time the context 
menu is displayed, nsMenuFrame::Init doesn't get called for the submenus until 
the submenu is about to be displayed.  I can reliably check GetIsContextMenu(), 
which returns PR_TRUE.  So the first time the context menu is displayed, the 
submenus have the mIsContextMenu flag set to PR_TRUE.

Each subsequent time that the context menu is displayed, nsMenuFrame::Init gets 
called (and thus the submenus are created) as the top-level context menu is 
being displayed.  This is before SetIsContextMenu(PR_TRUE) is called for the 
context menu, so GetIsContextMenu() returns PR_FALSE.  And this means that the 
submenus have mIsContextMenu set to PR_FALSE.

I haven't been able to track down this behavior, namely the timing of the 
submenu creation.  If I could, I think that I could knock off this bug.
Mass moving M18 bugs to M19
Target Milestone: M18 → M19
This is where I'd like to add the 'patch' keyword, but can't due to permissions.  
Just in case nobody noticed, there's a patch for this bug.
Keywords: patch
pushing into m17 since there is a patch from an external contributor.
Target Milestone: M19 → M17
marking nsbeta2 so i can get dean's patch landed via the system.
Keywords: nsbeta2
Putting on [nsbeta2-] radar.  Go thru brendan and mozilla to get checked in.
Whiteboard: [nsbeta2-]
Mass-moving all nsbeta2- bugs to M20
Target Milestone: M17 → M20
Target Milestone: M20 → Future
-> future
There's a patch for it and it gets moved to the future milestone??
oops, didn't see that.
Keywords: nsbeta3
Target Milestone: Future → M22
patch landed. thanks again dean!
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
(Changed Platform and OS to all, since it affected all platforms not just 
Linux.)

Verified Fixed using 2000073108 on NT.
Status: RESOLVED → VERIFIED
OS: Linux → All
Hardware: PC → All
Build 2000-07-31-05M17: Mac 9.04, Linux 6.0
Also checked on mac and linux and appears fixed.
Component: XP Toolkit/Widgets: Menus → XUL
QA Contact: nbaca → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: