Closed Bug 38484 Opened 25 years ago Closed 15 years ago

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

Categories

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

defect

Tracking

(Not tracked)

RESOLVED WORKSFORME
Future

People

(Reporter: jruderman, Unassigned)

References

()

Details

(Keywords: polish, Whiteboard: [PL2:P3])

Attachments

(1 obsolete file)

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
add 4xp keyword
Keywords: 4xp
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
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
*** Bug 67593 has been marked as a duplicate of this bug. ***
I wana try this one too!
Assignee: av → peterlubczynski
Keywords: shockwave
Target Milestone: Future → mozilla0.9
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?
Status: NEW → ASSIGNED
Depends on: 72864
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.
This patch tells the gRollupListener->Rollup() before we dispatch PLUGIN_ACTIVATE. Reviews?
Keywords: patch
Whiteboard: [seeking review]
Rod, my patch may help you with your combo box bug.
r=saari
sr=attinasi
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.
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 dropdowns.
-->mozilla 0.9.1
Whiteboard: [seeking review]
Target Milestone: mozilla0.9 → mozilla0.9.1
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
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?
Dan, this is probably a bug on Linux as well (if that is your development platform).
Assignee: peterlubczynski → dr
Status: ASSIGNED → NEW
I'm sure it is... I wonder if we couldn't do this in an XP way, though...
Status: NEW → ASSIGNED
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
Priority: P3 → P2
->0.9.3, cc karnaze in case this is really a showstopper.
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Kevin, I think this is the bug that Rod's new patch may help with. If so, can you reference the bug # here? Thanks!
Priority: P2 → P4
Target Milestone: mozilla0.9.3 → mozilla1.0
[spam] working on toolkit: plugins bugs => plugins team.
Assignee: dr → peterlubczynski
Status: ASSIGNED → NEW
Target Milestone: mozilla1.0 → ---
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.4
Target Milestone: mozilla0.9.4 → mozilla0.9.5
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
OS: Windows 98 → All
Hardware: PC → All
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.
this is still occuring on my win branch as mentioned initially. On mac, this is not seen, however bug 75456 is seen.
not a stop ship
Keywords: nsbranchnsbranch-
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Blocks: 107067
Keywords: nsbranch-
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
Target Milestone: mozilla0.9.7 → mozilla0.9.8
Target Milestone: mozilla0.9.8 → mozilla1.0
if this is a P4/Minor, should we push it off to after 1.0?
Severity: minor → normal
Priority: P4 → P3
Keywords: helpwantedpatch
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.
Attachment #29827 - Flags: superreview+
Attachment #29827 - Flags: review+
Patch in trunk, marking FIXED.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
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).
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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+
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.
*** 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. ***
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 adt@netscape.com. You can search for "Moving bugs not scheduled for a project" to quickly delete this bugmail.
Target Milestone: mozilla1.0 → mozilla1.2
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.
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.
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]
based on peter's last comment, adding dependency on bug 132759 and setting to future
Depends on: 100%CPU
Target Milestone: mozilla1.2alpha → Future
*** Bug 107853 has been marked as a duplicate of this bug. ***
*** 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
Status: REOPENED → NEW
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.
Status: NEW → RESOLVED
Closed: 23 years ago15 years ago
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: