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)
Core
XUL
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.
Assignee | ||
Comment 1•24 years ago
|
||
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.
Comment 3•24 years ago
|
||
Setting QA Contact to nbaca, adding lchiang to Cc: list.
QA Contact: lchiang → nbaca
Assignee | ||
Comment 4•24 years ago
|
||
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...
Assignee | ||
Comment 6•24 years ago
|
||
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.
Comment 11•24 years ago
|
||
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.
Assignee | ||
Comment 12•24 years ago
|
||
pushing into m17 since there is a patch from an external contributor.
Target Milestone: M19 → M17
Assignee | ||
Comment 13•24 years ago
|
||
marking nsbeta2 so i can get dean's patch landed via the system.
Keywords: nsbeta2
Comment 14•24 years ago
|
||
Putting on [nsbeta2-] radar. Go thru brendan and mozilla to get checked in.
Whiteboard: [nsbeta2-]
Updated•24 years ago
|
Target Milestone: M20 → Future
Comment 16•24 years ago
|
||
-> future
Comment 17•24 years ago
|
||
There's a patch for it and it gets moved to the future milestone??
Assignee | ||
Comment 18•24 years ago
|
||
oops, didn't see that.
Keywords: nsbeta3
Target Milestone: Future → M22
Assignee | ||
Comment 19•24 years ago
|
||
patch landed. thanks again dean!
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 20•24 years ago
|
||
(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
Comment 21•24 years ago
|
||
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.
Description
•