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...
reassign to cmanske and cc brade
Assignee: beppe → cmanske
Priority: -- → P3
Target Milestone: --- → mozilla0.9
Wow! This is like, totally weird, man!
Status: NEW → ASSIGNED
seen on linux and mac too. OS :ALL
OS: Windows NT → All
Hardware: PC → All
Severity: normal → major
Summary: Right click, popup submenus do not work the second time → Right click, context submenus do not work the second time
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
May be related to bug 68164.
I thought that at first, but 68164 is now fixed, but our problem still exists.
*** Bug 68385 has been marked as a duplicate of this bug. ***
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...)
giving to pinkerton who has more xp menu mojo than I do
Assignee: saari → pinkerton
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. |\
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.
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?
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... |\ )
2001030608/Linux works fine.
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.
I filed the new crash moving mail as bug 71184.
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.
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME
*** Bug 75909 has been marked as a duplicate of this bug. ***
verified in 5/7 build.
Status: RESOLVED → VERIFIED
Now we have bug 78725.
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.