Right click, context submenus do not work the second time

VERIFIED WORKSFORME

Status

()

P3
critical
VERIFIED WORKSFORME
18 years ago
11 years ago

People

(Reporter: shrir, Assigned: mikepinkerton)

Tracking

({regression})

Trunk
mozilla0.9
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

18 years ago
Seen on today's trunk 20010206 windows

Steps :
1 Launch Composer
2 Click on 'Table' button in Composition Toolbar
3 Select the default setting and press OK to add table
4 Now, right click inside the first cell and move mouse over the menus 'Table 
Insert; Table Select; Table Delete' (they should expand and submenus shud b 
seen)
5 Do not click anything and just dismiss this popup menu.
6 Again, in the same cell, do step 4. Observe that the menus do not expand and   
no submenus are seen.

cc'ing paw since he mentioned this problem...

Comment 1

18 years ago
reassign to cmanske and cc brade
Assignee: beppe → cmanske
Priority: -- → P3
Target Milestone: --- → mozilla0.9

Comment 2

18 years ago
Wow! This is like, totally weird, man!
Status: NEW → ASSIGNED
Keywords: regression
(Reporter)

Comment 3

18 years ago
seen on linux and mac too. OS :ALL
OS: Windows NT → All
Hardware: PC → All
nominating... yowza.
Severity: normal → major
Keywords: nsbeta1
Summary: Right click, popup submenus do not work the second time → Right click, context submenus do not work the second time

Comment 5

18 years ago
I don't see anything in editor code that could cause this.
The context menu (in EditorContextMenuOverlay.xul) is a straightforward menu
with items hidden (collapsed) and enabled at runtime. No dynamic adding of
menuitems or submenus.
It doesn't matter if you use a command during first popup or not. After used
once, the submenus no longer appear with subsequent popup launches!
It must be a XPFE problem.
Assignee: cmanske → saari
Severity: major → critical
Status: ASSIGNED → NEW

Comment 6

18 years ago
May be related to bug 68164.

Comment 7

18 years ago
I thought that at first, but 68164 is now fixed, but our problem still exists.

Comment 8

18 years ago
*** Bug 68385 has been marked as a duplicate of this bug. ***

Comment 9

18 years ago
This also seems to affect context submenus under Mailnews ("File under" etc.)
Definitely seems like a toolkit problem, at least to my amateur eye. Real pest, too.

Could the component at least be reassigned as XP-related instead? (In bug 68385,
the dup I wound up filing, I marked it as XPT/Widgets: Menus...)

Updated

18 years ago
Component: Editor → XP Toolkit/Widgets: Menus

Comment 10

18 years ago
giving to pinkerton who has more xp menu mojo than I do
Assignee: saari → pinkerton

Comment 11

18 years ago
BTW, I don't think anyone noted this yet...But if only one context submenu is
expanded and not any of the others, only that particular submenu will refuse to
expand in future instances of the context menu after dismissal. The others will
work (But ostensibly until after the context menu is dismissed).

 This is particularly noticable in mailnews-If you use the "Move To..." submenu
set under the message list pane, then the one under the message viewing pane,
you can give yourself two "chances" (As you're dealing with two different types
of context menus).

 It's a bother training myself to use the menubar for everything, but I'm
getting by. |\
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED
ok, i see this. the last thing to have changed is when ben whacked the 
positioning code. perhaps he has a hand in this, since i certainly haven't 
touched any menu code.

Comment 13

18 years ago
This is most probably a dup od bug 67736 (reported earlier and more dups at this 
point). However this bug has a more general summary. What should we do?

Comment 14

18 years ago
 Yeah, seems like...

 You know, if we don't want to lose this summary here or the deps over there,
can't this bug just be set to block 67736 instead of resolving as a dupe? I
mean, in a stricter sense I suppose it IS preventing resolution of the
side-effect listed in the earlier bug. =)

 Or am I missing something obvious? (Being an amateur, I may well be... |\ )

Comment 15

18 years ago
2001030608/Linux works fine.

Comment 16

18 years ago
2001030605/Win32 Installer works too, but there is another  problem. On the
first time I tried to move multiple messages (about 20), Mozilla opened more
than 10 empty Mail windows and crashed. I checked that the he messages were
actually moved. Later, I managed to move even nore messages (several times)
using the Right-click.

I confirm the bug fxed. I'll check bugzilla for the other (new?) bug as well
and, if necessary, file it.

Comment 17

18 years ago
I filed the new crash moving mail as bug 71184.

Comment 18

18 years ago
I don't see this problem any more, although pinkerton has not done anything to
fix it!
wfm as well, on linux, mac and winnt [2001.03.07.xx comm bits]. tempted to mark
this wfm, but not sure if there *was* a checkin from someone else that'd've
fixed this.

Comment 20

18 years ago
Yep, I can confirm WFM on 2001030714 Linux tar.gz. Good riddance...

 sairuh: From my (thus far brief) experience as a reporter, many
bugs/regressions such as this one get fixed without a checkin directly fixing
them...These usually end up being written off as WORKSFORME instead of FIXED,
likely due to a fix never being directly in hand, I suppose. But it's still a
resolution...>shrug<
i just wish i knew what changed to regress this, and then what changed to fix it 
:( I haven't touched xpmenus in at least 6 months.
wfm
marking wfm.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME

Comment 24

18 years ago
*** Bug 75909 has been marked as a duplicate of this bug. ***

Comment 25

18 years ago
verified in 5/7 build.
Status: RESOLVED → VERIFIED

Comment 26

18 years ago
Now we have bug 78725. 

Updated

11 years ago
Component: XP Toolkit/Widgets: Menus → XUL
QA Contact: sujay → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.