Closed Bug 210580 Opened 21 years ago Closed 19 years ago

[AxPlugin] ActiveX plugin overriding Mozilla native plugin

Categories

(Core Graveyard :: Embedding: ActiveX Wrapper, defect)

Product:
Core Graveyard
Component:
Embedding: ActiveX Wrapper
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED EXPIRED

People

(Reporter: alther, Assigned: adamlock)

References

(
URL
)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425

I have Flash 5 installed on IE.  I installed Flash 6.0 r79 on Moz 1.3.1.  I went
to http://macromedia.com and the flash simply does not come up.  I can right
click in the flash area and bring up the popup menu, and it says "About Flash
5".  Obviously, it's picking up the ActiveX version instead of the Mozilla
version of the plugin.

Once I renamed the "npmozax.dll" to a non-Netscape plugin name, the native
Mozilla Flash plugin was properly found.

If I install the latest Flash plugin for IE, then the Flash works except for the
links or Javascript interaction.

I did some searching, and bug 170349 looks like it might cover this, but I'm not
sure.

Also, see bug 203171, as I attributed these problems to something else.


Reproducible: Always

Steps to Reproduce:
1. Start up IE and install the IE Flash plugin (preferably a different version
than the Mozilla one: e.g. 5 or 6.0 r47).  Close IE.
2. Install the Mozilla Flash plugin.
3. Install the Mozilla ActiveX plugin.
4. Visit some Flash websites (e.g. http://macromedia.com, http://scubapro.com)
5. If you installed a different version of Flash for IE, the simply right click
on the Flash and click the About menu item.  You will notice the version # for
the IE plugin is displayed.
6. If they are the same version, then the Flash will visibly work, but non-of
the links in the Flash work if you click on them.
7. Rename the "npmozax.dll" to "_npmozax.dll" and restart Mozilla.  Retry the
above steps and notice everything works fine.

Actual Results:  
The ActiveX plugin is being used in preference to the native Mozilla plugin.

Expected Results:  
I expect Mozilla to check to see if any Native plugins can handle the specific
MIME type first before checking the ActiveX plugin.  There should be some sort
of order or priority for these plugins, and not just for ActiveX.  If two or
more plugins claim they handle the same MIME type, there should be some ordering
(preferably user defined if possible..or maybe it's install order), to determine
which plugin handles it.
Is there the difference of flash plugin is installed [mozilla/plugin] dir from
other dir? 
This also happens on Moz 1.4rc3 as well as 1.3.1

Anyilove, I'm not sure what you are asking.
* The Mozilla Flash and ActiveX plugins are installed in the /plugins directory.
* The IE Flash ActiveX control is installed wherever it gets installed.

The problem is that when the Moz ActiveX plugin is installed, it seems to take
precedence over native Moz plugins and runs the ActiveX Flash control rather
than the Moz Flash plugin.
How was the Active-X plugin installed? Be sure you have the Active-X security
policy because that regulates the ussage of the Netscape plugin.
The ActiveX plugin was installed from here:
http://www.iol.ie/~locka/mozilla/plugin.htm#download

I was unaware of the activex.js preferences file.  Even so, I have no idea what
I would need to put in there to prevent the ActiveX version of Flash from
running.  I certainly don't know the ClassID of the Flash ActiveX control.
I've attempted to find out the Class IDs of the ActiveX Flash object and this is
what I've put into the activex.js file so far with no luck.  The Flash ActiveX
control is still loading:

pref("capability.policy.default.ClassID.CID1171A62F-05D2-11D1-83FC-00A0C9089C5A",
"NoAccess");
pref("capability.policy.default.ClassID.CIDD27CDB70-AE6D-11cf-96B8-444553540000",
"NoAccess");
pref("capability.policy.default.ClassID.CIDD27CDB6E-AE6D-11cf-96B8-444553540000",
"NoAccess");
pref("capability.policy.default.ClassID.CIDD27CDB6B-AE6D-11CF-96B8-444553540000",
"NoAccess");


-->adam
Assignee: peterlubczynski → adamlock
Component: Plug-ins → Embedding: ActiveX Wrapper
QA Contact: bmartin → mdunn
Would it be possible to have an option to always load the EMBED instead of the
OBJECT if a plugin exists for it?
Oh, I guess they are semi-interchangable.  What I mean to say is: can we always
attempt to load a native plugin first and only use the ActiveX plugin if a
native handler is not found.
EMBED tags inside OBJECT tags should be favoured. If that isn't happening, it
sounds like a problem with the plugin API rather than the ActiveX plugin which
is only doing what it's told.
Summary: ActiveX plugin overriding Mozilla native plugin → [AxPlugin] ActiveX plugin overriding Mozilla native plugin
I'm having exactly the same problem. I installed the Mozilla ActiveX control and
now flash doesn't work properly, i.e. I cannot click in flash objects etc.

To prove that Mozilla ActiveX control _is_ the culprit:

I then moved npmozax.dll out of C:\Program Files\Mozilla FireFox\plugins . And
now everything is OK. So the mozilla activex control is interfering with flash!!!

about:plugin info:

Shockwave Flash

    File name: NPSWF32.dll
    Shockwave Flash 7.0 r19

MIME Type 	Description 	Suffixes 	Enabled
application/x-shockwave-flash 	Macromedia Flash movie 	swf 	Yes
application/futuresplash 	FutureSplash movie 	spl 	Ye


Mozilla ActiveX control and plugin support

    File name: npmozax.dll
    Mozilla ActiveX control and plugin module

MIME Type 	Description 	Suffixes 	Enabled
application/x-oleobject 	ActiveX 	*.ocx 	Yes
application/oleobject 	ActiveX 	*.ocx 	Yes


Thanks!
*** Bug 240981 has been marked as a duplicate of this bug. ***
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → EXPIRED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.