native context menu for plug-in doesn't close mozilla context menu for browser




19 years ago
9 years ago


(Reporter: jruderman, Unassigned)



Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [PL2:P3], URL)


(1 obsolete attachment)



19 years ago
Steps to reproduce:
1. Go to
2. Make sure at least one of the shockwave movies appears and is on your screen
3. Right-click somewhere other than the movie
4. Right-click on the movie

Actual result: two context menus open after step 4
Expected result: context menu from step 3 closes at step 4

Comment 1

19 years ago
add 4xp keyword
Keywords: 4xp

Comment 2

19 years ago
this is a stale bug. it still reproduce on the win NT platform on the 2000072608
build in mozilla. it still reproduce at said by the original report

Comment 3

19 years ago
for the records..this is still happening..
Future. Netscape engineer this bug is assigned to is overburdened.
 Not a N6 RTM blocker because you need to do a slightly odd series of events to
trigger the bug, and it's not critical.
Target Milestone: --- → Future

Comment 5

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

Comment 6

18 years ago
I wana try this one too!
Assignee: av → peterlubczynski
Keywords: shockwave
Target Milestone: Future → mozilla0.9

Comment 7

18 years ago

How do you tell the app to roll up all open conext menus. Not only in it's own 
WEBSHELL, but others like the chrome too? What about embedders? Is there a way 
to do this?


18 years ago
Depends on: 72864

Comment 9

18 years ago
if you're in widget, get the gRollupListener and tell it to rollup.

On windows, we're going to have to do this from widget where we specially handle
plugin focusing. 

Comment 10

18 years ago
Created attachment 29827 [details] [diff] [review]
patch to rollup menus before dispatching focus to plugin

Comment 11

18 years ago
This patch tells the gRollupListener->Rollup() before we dispatch 

Keywords: patch
Whiteboard: [seeking review]

Comment 12

18 years ago
Rod, my patch may help you with your combo box bug.

Comment 13

18 years ago

Comment 14

18 years ago

Comment 15

18 years ago
Kevin doesn't think this patch is ready to go in. I'm just rolling up the 
context menu anytime I get an activate which is wrong (but sort works in some 
cases). I think there is already logic in nsWindow to decide when to roll up but 
 I'm not quite sure what to do here.

Comment 16

18 years ago
Why is rolling it up when you get an activate wrong?
FYI: I don't think that the mozilla context menu will rollup in all cases when
mozilla is embedded. Although this may not be an issue if the embedding app is
required to "fly" the context menu. If the user clicks on a window that was
created by the app doing the embedding the event will go directly to the
embedding applications window event handler bypassing the code in nsWindow.cpp
which handles the rollup. This is what happens in MFCEmbed with comboboxes.  If
you drop down the combobox and click on the chrome in MFCEmbed the combobox does
not rollup. I'm sure that this will also happen if you could bring up the
mozilla context menu in MFCEmbed. 

At some point, probably soon, we will need a solution to rollup all dropdowns
when an event is passed to the embedding application. 

There are three approaches we could take to rolling up the dropdowns:

1. Add a new method to the embedding API's and leave it up the embedding app to
rollup the dropdowns.

2. initiate mouse-capture while the drop-down is up. This is what native
comboboxes do. However, This will not work with our current combobox
implementation because we use a native scrollbar. If we initiate mouse-capture
on the combobox dropdown then we can not scroll the combobox items.  

3. Look for an event that gets sent to the Mozilla nsWindow when the user clicks
on a window in the embedding application. Using spy++, I don't see any events
passed to the Mozilla nsWindow when the user clicks on the chrome in MfcEmbed so
I don't think there is a way to get an event which we can use to roll up the

Comment 18

18 years ago
-->mozilla 0.9.1
Whiteboard: [seeking review]
Target Milestone: mozilla0.9 → mozilla0.9.1

Comment 19

18 years ago
Can we hook into DealWithPopups() in nsWindow.cpp as comboboxs have:
// Handle events that may cause a popup (combobox, XPMenu, etc) to need 
to rollup.
nsWindow :: DealWithPopups ( UINT inMsg, WPARAM inWParam, LPARAM inLParam, 
LRESULT* outResult )

cc:ing pinkerton as it looks like he was in there last for XP popups
saari mentioned there was some kind of activate/deactivate msg that we would get 
when another window came up over our context menu. saari, do you recall that we 
had in your cube?

Comment 21

18 years ago
Dan, this is probably a bug on Linux as well (if that is your development 
Assignee: peterlubczynski → dr

Comment 22

18 years ago
I'm sure it is... I wonder if we couldn't do this in an XP way, though...

Comment 23

18 years ago
TM to 0.9.2 per PDT triage (it's OK to check it in by Friday or after 0.9.1
branch is made).
Target Milestone: mozilla0.9.1 → mozilla0.9.2


18 years ago
Keywords: patch → mozilla0.9.1, nsCatFood, polish


18 years ago
Priority: P3 → P2

Comment 24

18 years ago
->0.9.3, cc karnaze in case this is really a showstopper.
Target Milestone: mozilla0.9.2 → mozilla0.9.3

Comment 25

18 years ago

I think this is the bug that Rod's new patch may help with. If so, can you 
reference the bug # here?



18 years ago
Priority: P2 → P4


18 years ago
Target Milestone: mozilla0.9.3 → mozilla1.0

Comment 27

18 years ago
[spam] working on toolkit: plugins bugs => plugins team.
Assignee: dr → peterlubczynski
Target Milestone: mozilla1.0 → ---


18 years ago
Target Milestone: --- → mozilla0.9.4


18 years ago
Target Milestone: mozilla0.9.4 → mozilla0.9.5

Comment 28

18 years ago
I think this happens on Mac too. I think we need a more generic way to ensure
xul context menus rollup if native ones are activated inside a plugin. adding
Keywords: shockwave → helpwanted, nsbranch
OS: Windows 98 → All
Hardware: PC → All

Comment 29

18 years ago
There aren't any comments on this bug since the 7th of
Sept.  Can QA regess against the Netscape commercial builds and determine if
this is still a valid bug?  If so, and we can get fixes/reviews in the next day
or two, please mark as nsbranch+ which will get this on the PDT radar. Else,
mark is as nsbranch-. Also, can someone comment in the bug how serious you think
this is?  PDT is only accepting "stop ship" bugs such as data loss and loss of
major functionality.

Comment 30

18 years ago
this is still occuring on my win branch as mentioned initially. On mac, this is 
not seen, however bug 75456 is seen.

Comment 31

18 years ago
not a stop ship
Keywords: nsbranch → nsbranch-


17 years ago
Target Milestone: mozilla0.9.5 → mozilla0.9.6


17 years ago
Blocks: 107067


17 years ago
Keywords: nsbranch-

Comment 32

17 years ago
Maybe for starters, this can just be fixed for internal mozilla events, not
including native windows?

Does anyone know if there is a way I can register to capture all mozilla mouse
events? I was thinking if that was possible then when I got a CONTEXTMENU event,
I would capture the mouse and tell my plugin to rollup.
Target Milestone: mozilla0.9.6 → mozilla0.9.7


17 years ago
Target Milestone: mozilla0.9.7 → mozilla0.9.8


17 years ago
Target Milestone: mozilla0.9.8 → mozilla1.0
if this is a P4/Minor, should we push it off to after 1.0?


17 years ago
Severity: minor → normal
Priority: P4 → P3


17 years ago
Keywords: helpwanted → patch

Comment 34

17 years ago
Comment on attachment 29827 [details] [diff] [review]
patch to rollup menus before dispatching focus to plugin

The patch in this bug is still good. I just tested and it does the right thing,
even in MFCEmbed with combo boxes. It already has r/sr by sarri/attinasi in
comment #13 and comment #14.

I plan on landing it soon unless anyone has any objectections to rolling up on
Attachment #29827 - Flags: superreview+
Attachment #29827 - Flags: review+

Comment 35

17 years ago
Patch in trunk, marking FIXED.
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 36

17 years ago
er, sorry. Reopening. This broke the following:

1) click on 'File' menu in browser to open File menu popup
2) click again on 'File' to roll it up

Expected: popup rolls up on a second click
Actual: popup apparently won't roll up 

I have reverted and applied the two-line patch for this bug, and with the 
patch, in a current win2k build, you cannot dismiss an open menu by clicking
on 'File'. [You can dismiss by clicking elsewhere, e.g., the titlebar).
Resolution: FIXED → ---

Comment 37

17 years ago
Comment on attachment 29827 [details] [diff] [review]
patch to rollup menus before dispatching focus to plugin

Patch backed out, will come up with better solution.
Attachment #29827 - Attachment is obsolete: true
Attachment #29827 - Flags: superreview+
Attachment #29827 - Flags: review+
Attachment #29827 - Flags: needs-work+

I think there is a bigger issue here that should be fixed.

When a popupmenu is displayed, Mozilla should be capturing the mouse to 
guarantee that the next mouse click always dismisses the menu. It can then pass 
that click on to the appropriate application.

Comment 39

17 years ago
*** Bug 125312 has been marked as a duplicate of this bug. ***
Should this bug be dependant on bug 123582 ?
*** Bug 125458 has been marked as a duplicate of this bug. ***

Comment 42

17 years ago
Moving Netscape owned 0.9.9 and 1.0 bugs that don't have an nsbeta1, nsbeta1+,
topembed, topembed+, Mozilla0.9.9+ or Mozilla1.0+ keyword.  Please send any
questions or feedback about this to  You can search for
"Moving bugs not scheduled for a project" to quickly delete this bugmail.
Target Milestone: mozilla1.0 → mozilla1.2

Comment 43

17 years ago
Interesting.  On Windows, if I pop up a Mozilla context menu and then a Flash
context menu, the Moz context menu goes away as soon as I highlight a menu item
in the Flash context menu.

Comment 44

17 years ago
Probably this bug refers to unix platfors only. The reason is the problem
with dispatching of events through several toolkits (Xt is used for plugins
and Gtk for browser); in this case events from plugin cannot be catched by

Some details can be found in bug 95541 (and fix for propagating of events
from plug-in to browser). If so, we can close this bug as dup of 95541.

Comment 45

17 years ago
After investigating bug 132759 in detail, I found that subclassing the plugin
window after the plugin does seems to also resolve this bug! Since that may
involve some risky platform toolkit code, this bug is planed for plugins 2.0 work.
Whiteboard: [PL2:P3]

Comment 46

17 years ago
based on peter's last comment, adding dependency on bug 132759 and setting to future
Depends on: 132759
Target Milestone: mozilla1.2alpha → Future

Comment 47

15 years ago
*** Bug 107853 has been marked as a duplicate of this bug. ***

Comment 48

15 years ago
*** Bug 107853 has been marked as a duplicate of this bug. ***
QA Contact: shrir → plugins
Neil, something which can be worked on in the near future?
Assignee: peterlubczynski-bugs → nobody
Duplicate of this bug: 404297
Most cases were fixed by bug 453617, bug 294688 and XUL popup refactoring.

I think that there is only bug 404297 which is a bug only on Windows.

So, now, this can be marked as WFM and bug 404297 should be reopened.
Last Resolved: 17 years ago9 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.