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

Status: RESOLVED WORKSFORME

(Core Graveyard :: Plug-ins, defect, P3)

Description

[Jesse Ruderman]

Steps to reproduce:
1. Go to http://www.macromedia.com/shockwave/welcome/
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

[sean echevarria]

add 4xp keyword

Comment 2

[kenneth buttler]

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

[shrirang khanzode]

for the records..this is still happening..

Comment 4

[ekrock's old account (dead)]

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.

Comment 5

[Keyser Sose]

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

Comment 6

[Peter Lubczynski]

I wana try this one too!

Comment 7

[Peter Lubczynski]

Hyatt,

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?

Comment 8

[Peter Lubczynski]

Rod, any input?

http://lxr.mozilla.org/seamonkey/source/layout/html/forms/src/nsGfxTextControlFr
ame.cpp#4158

Comment 9

[saari (gone)]

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

[Peter Lubczynski]

Attachment: patch to rollup menus before dispatching focus to plugin

Comment 11

[Peter Lubczynski]

This patch tells the gRollupListener->Rollup() before we dispatch 
PLUGIN_ACTIVATE.


Reviews?

Comment 12

[Peter Lubczynski]

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

Comment 13

[saari (gone)]

r=saari

Comment 14

[Marc Attinasi]

sr=attinasi

Comment 15

[Peter Lubczynski]

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

[saari (gone)]

Why is rolling it up when you get an activate wrong?

Comment 17

[Kevin McCluskey (gone)]

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
dropdowns.

Comment 18

[Peter Lubczynski]

-->mozilla 0.9.1

Comment 19

[Peter Lubczynski]

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.
//
BOOL
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

Comment 20

[Mike Pinkerton (not reading bugmail)]

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

[karnaze (gone)]

Dan, this is probably a bug on Linux as well (if that is your development 
platform).

Comment 22

[Dan Rosen]

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

Comment 23

[Marek Z. Jeziorek]

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).

Comment 24

[Peter Trudelle]

->0.9.3, cc karnaze in case this is really a showstopper.

Comment 25

[Peter Lubczynski]

Kevin,

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

Thanks!

Comment 26

[rods (gone)]

My fix was for :
http://bugzilla.mozilla.org/show_bug.cgi?id=81416

Comment 27

[Dan Rosen]

[spam] working on toolkit: plugins bugs => plugins team.

Comment 28

[Peter Lubczynski]

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
helpwanted

Comment 29

[Cindy Roberts]

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

[shrirang khanzode]

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

Comment 31

[Peter Lubczynski]

not a stop ship

Comment 32

[Peter Lubczynski]

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.

Comment 33

[Jaime Rodriguez, Jr.]

if this is a P4/Minor, should we push it off to after 1.0?

Comment 34

[Peter Lubczynski]

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
WM_MOUSEACTIVATE.

Comment 35

[Peter Lubczynski]

Patch in trunk, marking FIXED.

Comment 36

[John Morrison]

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).

Comment 37

[Peter Lubczynski]

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.

Comment 38

[Mike Kaply [:mkaply]]

See:

http://bugzilla.mozilla.org/show_bug.cgi?id=123582

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

[John Morrison]

*** Bug 125312 has been marked as a duplicate of this bug. ***

Comment 40

[Vidar Haarr (not reading bugmail)]

Should this bug be dependant on bug 123582 ?

Comment 41

[[e-mail]]

*** Bug 125458 has been marked as a duplicate of this bug. ***

Comment 42

[scottputterman]

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 [e-mail].  You can search for
"Moving bugs not scheduled for a project" to quickly delete this bugmail.

Comment 43

[:deanis74]

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

[Sergi]

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
browser.

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

[Peter Lubczynski]

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.

Comment 46

[rubydoo123]

based on peter's last comment, adding dependency on bug 132759 and setting to future

Comment 47

[Robert Parenton]

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

Comment 48

[Robert Parenton]

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

Comment 49

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Neil, something which can be worked on in the near future?

Comment 51

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away until 10/14)]

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.