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)
Core Graveyard
Plug-ins
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
Comment 2•24 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•24 years ago
|
||
for the records..this is still happening..
Comment 4•24 years ago
|
||
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 6•24 years ago
|
||
I wana try this one too!
Comment 7•24 years ago
|
||
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
Comment 8•24 years ago
|
||
Rod, any input?
http://lxr.mozilla.org/seamonkey/source/layout/html/forms/src/nsGfxTextControlFr
ame.cpp#4158
Comment 9•24 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•24 years ago
|
||
Comment 11•24 years ago
|
||
This patch tells the gRollupListener->Rollup() before we dispatch
PLUGIN_ACTIVATE.
Reviews?
Keywords: patch
Whiteboard: [seeking review]
Comment 12•24 years ago
|
||
Rod, my patch may help you with your combo box bug.
Comment 13•24 years ago
|
||
r=saari
Comment 14•24 years ago
|
||
sr=attinasi
Comment 15•24 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•24 years ago
|
||
Why is rolling it up when you get an activate wrong?
Comment 17•24 years ago
|
||
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•24 years ago
|
||
-->mozilla 0.9.1
Whiteboard: [seeking review]
Target Milestone: mozilla0.9 → mozilla0.9.1
Comment 19•24 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.
//
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•24 years ago
|
||
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•24 years ago
|
||
Dan, this is probably a bug on Linux as well (if that is your development
platform).
Assignee: peterlubczynski → dr
Status: ASSIGNED → NEW
Comment 22•24 years ago
|
||
I'm sure it is... I wonder if we couldn't do this in an XP way, though...
Status: NEW → ASSIGNED
Comment 23•24 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
Comment 24•24 years ago
|
||
->0.9.3, cc karnaze in case this is really a showstopper.
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Comment 25•24 years ago
|
||
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•24 years ago
|
||
My fix was for :
http://bugzilla.mozilla.org/show_bug.cgi?id=81416
Comment 27•23 years ago
|
||
[spam] working on toolkit: plugins bugs => plugins team.
Assignee: dr → peterlubczynski
Status: ASSIGNED → NEW
Target Milestone: mozilla1.0 → ---
Updated•23 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.4
Updated•23 years ago
|
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Comment 28•23 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
helpwanted
Comment 29•23 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•23 years ago
|
||
this is still occuring on my win branch as mentioned initially. On mac, this is
not seen, however bug 75456 is seen.
Updated•23 years ago
|
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Comment 32•23 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
Updated•23 years ago
|
Target Milestone: mozilla0.9.7 → mozilla0.9.8
Updated•23 years ago
|
Target Milestone: mozilla0.9.8 → mozilla1.0
Comment 33•23 years ago
|
||
if this is a P4/Minor, should we push it off to after 1.0?
Updated•23 years ago
|
Severity: minor → normal
Priority: P4 → P3
Updated•23 years ago
|
Keywords: helpwanted → patch
Comment 34•23 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
WM_MOUSEACTIVATE.
Attachment #29827 -
Flags: superreview+
Attachment #29827 -
Flags: review+
Comment 35•23 years ago
|
||
Patch in trunk, marking FIXED.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 36•23 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).
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 37•23 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+
Comment 38•23 years ago
|
||
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•23 years ago
|
||
*** Bug 125312 has been marked as a duplicate of this bug. ***
Comment 40•23 years ago
|
||
Should this bug be dependant on bug 123582 ?
Comment 41•23 years ago
|
||
*** Bug 125458 has been marked as a duplicate of this bug. ***
Comment 42•23 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 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
Comment 43•23 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•23 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
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•22 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•22 years ago
|
||
based on peter's last comment, adding dependency on bug 132759 and setting to future
Depends on: 100%CPU
Target Milestone: mozilla1.2alpha → Future
Comment 47•21 years ago
|
||
*** Bug 107853 has been marked as a duplicate of this bug. ***
Comment 48•21 years ago
|
||
*** Bug 107853 has been marked as a duplicate of this bug. ***
Updated•15 years ago
|
QA Contact: shrir → plugins
Comment 49•15 years ago
|
||
Neil, something which can be worked on in the near future?
Assignee: peterlubczynski-bugs → nobody
Status: REOPENED → NEW
Comment 51•15 years ago
|
||
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 ago → 15 years ago
Resolution: --- → WORKSFORME
Updated•3 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•