55822 - The context menus for Shockwave and Flash movies do not work in Netscape 6 PR3

Status: VERIFIED FIXED

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

Description

[Mark Aguirre]

1. Download and execute a clean installation of Netscape 6 PR3 for the 
Macintosh from http://home.netscape.com/download/0927100/10004-en-macppc---
_qual.html
2. Download and execute the Tron Full No Pinging Stand Alone installer from 
http://quixote.macromedia.com/shockwave/sdc/850130/SW850130_FullNoPing.hqx
3. Play either the Shockwave movie at 
http://intranet.shockwave.com/dept/qa/shockwave/content/shockwavemovie.html or 
the Flash movie at 
http://intranet.shockwave.com/dept/qa/shockwave/content/falsh.html, and try to 
activate the context menu.
Results: The context menu is not functioning.
Expected: The context menus should function properly.

Comment 1

[shrirang khanzode]

I confirm this bug. Assign: peterl. This was working earlier, for sure. keyword: 
rtm

Comment 2

[shrirang khanzode]

reassign

Comment 3

[shrirang khanzode]

note :this is not working on windows for quicktime too. (windows br build 
2000100908)

Comment 4

[Peter Lubczynski]

..accepting.
I think I found the problem on the Mac. Looks like we were only looking for the 
left button down event on the frame whereas on the Mac, context menu clicking 
(CONTROL+CLICK) sends a right button down event. That was never being passed to 
the plugin. Partial fix-in-hand.

The rest of the problem is that I still get the context menu for the browser 
after the context menu for the plugin is finished. I'm still working on trying 
to figure out what's going on.

I don't remember plugin context menus ever working correctly on the Mac. Perhaps 
it was before I came on board. 

cc:ing ekrock

Comment 5

[Peter Lubczynski]

This is a much bigger problem than simply detecting for a right mouse down 
during event delegation in nsObjectFrame. nsObjectFrame should really be a DOM 
Listener and get events that way rather than through HandleEvent(). The problem 
with using HandleEvent() is that we can not consume the DOM event and therefore 
after displaying the plugin context menu, we will always get the browser's 
context menu because the DOM gets the event first.

Marking as blocked by 56028 which deals with making nsObjectFrame a DOM Listener

Comment 6

[karnaze (gone)]

Reassigning to myself and adding [rtm need info].

Comment 7

[karnaze (gone)]

Peterl, back to you for testing Kevin's patch (bug 56028) on the MAC.

Comment 8

[Peter Lubczynski]

Attachment: patch from bug 56028 which fixes this issue

Comment 9

[buster]

a=buster.  sorry it took so long, networking and bugzilla downtime!

Comment 10

[Peter Lubczynski]

whoho!!!

marking rtm+ per karnaze's approval and review

Comment 11

[ekrock's old account (dead)]

PDT: This is a critical blocker for plug-in support on the Mac. Blocks ability 
to control Flash, Shockwave, and other top-tier plug-ins via their standard, 
built-in context menu controls that users have been using since Nav2. Correcting 
priority to P1 as this affects high-profile partners and is a high-profile 
backward compatibility issue. If PDT is considering not taking this patch, 
please call me and we'll come to Star Trek to explain why this is critical.

Comment 12

[Peter Lubczynski]

Marc,

Can you check this patch out on Linux. You should get a "plugin" context menu 
and NOT see the Mozilla one.

Thanks.

Comment 13

[Peter Lubczynski]

This patch appears to fix Qucktime, Flash, and Shockwave on the Mac.

However, it does NOT fix the context menu on Quicktime on Win32. You still get
Mozilla's context menu. There is already a bug on this: bug 32668

Comment 14

[Peter Trudelle]

PDT says rtm need info, please land on trunk, bake for 24 hours while pounding
on it.

Comment 15

[saari (gone)]

Just so you know, this is an OK short term fix, but long term this handling
needs to move out of a DOM listener or into a DOM event "group" (Tom, help me
out with the current working name for this in DOM L3). The problem is that a
page could set up a DOM event handler of its own and cancel the click before the
plugin should even see it. As it stands there is no defined ordering of DOM
event listeners, which is what the "event groups" will address.

Don't feel bad, text fields/areas suffer from the same problem currently. Just
be aware of the issue.

Comment 16

[ekrock's old account (dead)]

Peter, please get sr= ASAP if that's still necessary, then check in on trunk
ASAP and bake per PDT, then if all goes well notify PDT and get rtm++. Thanks!

Comment 17

[Peter Lubczynski]

That's my top priority today. I'm getting my trunk build updated right now as it 
hasn't been updated in a while then I'm going to prepare the patch.

Another good reason to include this patch into RTM is that from a plugin's 
context menu like Flash, there is the option to Print and go to Hi/Low res. 
Without this menu, this functionality is lost.

Comment 18

[Peter Lubczynski]

Attachment: revised patch with better placed asserts

Comment 19

[Peter Lubczynski]

In the revised patch, all I did was move the asserts around to the proper 
places. Tested on Win32 and Mac and double reviewed by Karnaze. Looks good.

Checked in on trunk for "bake time"

Comment 20

[Peter Lubczynski]

Well, this has been on the trunk for a few days, how's it going?

Comment 21

[Phil Peterson]

Why is this rtm+ again before any testing info from the trunk is available?
We're not just waiting for someone to scream, we want someone to really test it
and report that it works and doesn't regress anything else. Marking [rtm need info]

Comment 22

[shrirang khanzode]

Tested on mac trunk build 2000101908 using quicktime and flash :

Observations(MAC):
1 Quicktime plugin : Selecting 'Plug-in Settings' or 'About Quicktime Plug-in' 
from the context menu open up dialogs. I observe that the mouse cursor shows a 
busy state (rather than arrow)

2 Flaash 5.0 :When I open up the context menu on a flash page, the mouse cursor 
(for a brief period) appears as garbled up square shaped and then shows the busy 
icon.(should appear as a arrow)

3 Select the 'PRINT' option from flash context menu and click CANCEL or PRINT   
button. Observe that there is another PRINT window open behind this one.   

Yet to test on windows trunk. Will update soon.

Comment 23

[shrirang khanzode]

Disregard my comment about windows. This bug is mac specific. The windows bug is 
bug 32668 as peter mentioned. I have logged bugs to seperate this 
issue(plugin context menu) for each plugin (quicktime, flash). They are  bug 
57458 and bug 57459. Pls consider this bug for shockwave plugin only. Changing 
url, removing 'flash' keyword.

Comment 24

[karnaze (gone)]

This has baked for a week now on the trunk. shrirang says there have been no 
regressions reported.

Comment 25

[Phil Peterson]

This bug is in candidate limbo.  We will reconsider this fix once we have 
a candidate in hand, but we can't take this fix before then.

Comment 26

[selmer (gone)]

PDT marking [rtm++]. This bug is now out of limbo and approved for checkin to
the branch. Please check in ASAP.

Comment 27

[Peter Lubczynski]

This should work now. Patch checked into the branch. Marking FIXED.

Comment 28

[shrirang khanzode]

This is verified on the mac branch build 2000-10-31-14-MN6. Combination of 
CONTROL + mouse click works and context menus for flash,shockwave,quicktime are 
seen. Adding keyword:vtrunk

Comment 29

[shrirang khanzode]

this is working fine on trunk mac build 1127. Tested quicktime, shockwave and 
flash plugins for verification. Removing 'vtrunk' keyword and marking VERIFIED.