Closed Bug 215823 Opened 21 years ago Closed 13 years ago

[AxPlugin] Add "Windows Media Player" ActiveX support to Mozilla (Netscape 7.1 has it)

Categories

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

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

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: bugzilla, Unassigned)

Details

Attachments

(2 files)

Patch removes MOZ_USE_ACTIVEX_PLUGIN
841 bytes, patch
Details | Diff | Splinter Review
NS7.1 activex.js
352 bytes, patch
Details | Diff | Splinter Review 
Adam: following up on the email conversation we had about the missing Windows
Media Player ActiveX support in Mozilla.

Some sites including my employee (TDC teh largest ISP in Denmark) uses it, and
are currently not able to serve Mozilla users...:(

stuff some email conversation:
The nightly Mozilla builds do contain COMConnect support built into XPConnect
but it is disabled in the absence of the activex.js, nsAxSecurityPolicy.js (and
npmozax.dll for OBJECT tags) which are built by
mozilla/embedding/browser/activex/src/plugin but not copied to the dist/ dir.
CC some drivers.

Simple patch and NS7.1 version of activex.js follows
Summary: Add "Windows Media Player" ActiveX support to Mozilla (Netscape 7.1 has it) → [AxPlugin] Add "Windows Media Player" ActiveX support to Mozilla (Netscape 7.1 has it)
This patch removes the MOZ_USE_ACTIVEX_PLUGIN test in the makefile which stops
the plugin from installing after being built.
Attached patch NS7.1 activex.js — — Splinter Review 
This is the NS7.1 version of activex.js.

The settings allow hosting of safe for scripting controls (no download and
install), but enable a whitelist so only the WMP clsids can be instantiated.

The controversial thing about this file is the addition to the user agent of
'ax' in the comment. This was done so that sites had a way to do a server side
sniff before delivering ActiveX enabled content. The NS7.1 useragent looks like
this:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
Netscape/7.1 (ax)
As I've said, I think this platform-specific technology is inappropriate
for the web.  By supporting it we would be increasing the share of
browsers on which it is supported and thus encouraging its use.

The argument was raised in the email thread that this argument doesn't hold
for intranets, and is preventing adoption of Mozilla on corporate intranets.
(Users of Mozilla gained this way would also likely use it on the Web.)
This is a legitimate argument, so, as I proposed in email, I am strongly
opposed to enabling this for any sites other than those in the same domain
as the user.  (Perhaps domain isn't exactly the right mechanism, but
whatever the mechanism is, it should be designed so that it's very hard to
use on the web -- i.e., perhaps a preference for a *single* domain.)

(One of the things that holds WinIE's standards support back is that it
is fundamentally an intranet browser, not a Web browser, and thus they
stick to much tighter backwards-compatibility requirements (i.e., not
fixing bugs, intentionally).  I really don't want Mozilla to move in
that direction.  I'd like to focus our standards support on being a Web
browser.)
Cc'ing dveditz, whom I recalled was not in favor of the (ax) thing.  I too
didn't see the point, but now that Netscape 7.1 has shipped, maybe there's no
value to being different.

The question of whether to enable scriptable WMP is still being deliberated over
by drivers.

/be
I personally agree with dbaron.

Other points made over IRC and by e-mail:

Enabling Active X plugin glue does not suddenly make pages that use such plugins
work.  The constructor in an enabled Mozilla is window.GeckoActiveXObject, not
window.ActiveXObject, and it understands only a limited set of progids.  Almost
all pages that use Active X plugins depend on that constructor, and on other
elements of IE's proprietary DOM.  Then there are the "MSXML.*" and similar
progids used by some pages to access somewhat standard XML DOM interfaces, but
with a non-standard initialization sequence.

So Active X support looks an awful lot like the first step down a slippery slope
toward IE DOM and IE COM interface support.  If someone wants to evangelize a
few sites to use GeckoActiveXObject in a Netscape 7.1/Mozilla 1.? fork of its
content, and use ActiveXObject with IE progids and DOM features in the IE fork,
I would be interested in which sites, and with what evangelist workforce.

If anyone capable of doing the work actually wants to reverse-engineer the IE
DOM and the very-high-dimensionality feature-space of IE COM interfaces and
implementations, I would be greatly surprised. And in that case, I wouldn't want
such a thick emulation layer hosted by mozilla.org.

/be
Concerning platform specific technology, I am in favour of not encouraging the
widespread adoption of ActiveX. But content sites already using the WMP content
are already locking themselves into Win32 (with some support for the Mac) and
short of MS fixing scripting in their plugin it won't work very well in Mozilla.
For that reason and intranets, it seems sensible to go the extra yard and ship
the ActiveX support and maybe win a few new people over.

Regarding supporting the IE DOM. I already have a partial implementation of it
shared by my Mozilla control and plugin, and what I have already is 'just
enough' to keep the large majority of controls happy. Most controls just want
access to IWebBrowser to Navigate() somewhere else or check the current page
URL. I haven't seen a control which walks the DOM, but I suppose they must
exist. In this instance I would suggest we document the limits of the support
and not step over it.

So the issues are:

1. Do you want to distribute the ActiveX plugin & files we already build and how
is it packaged? It could be an option in the net installer for Moz, or an
extension for Firebird, or it could go in the GRE and benefit any embedding client.

2. What settings are most appropriate for it? Everything disabled, or support
for the WMP control. Do we set up some zones in the activex.js that intranet
developers can uncomment to support their controls.

Either settings would still mean the browser at large still favours the NPAPI
and standards but those who want it can flip a switch and get it.

The NPAPI definitely needs a bug if it doesn't already to cover sexing it up
with wizards and so on. Trying to produce an XPCOM scriptable plugin at the
moment is a nightmare. It wouldn't go amiss if the plugin SDK also shipped with
the DOM frozen interfaces to impress upon people how much plugins can do these days.
> But content sites already using the WMP content are already locking themselves
> into Win32 (with some support for the Mac) 

How do such sites support the Mac?

> Regarding supporting the IE DOM. I already have a partial implementation of
> it shared by my Mozilla control and plugin, and what I have already is 'just
> enough' to keep the large majority of controls happy. Most controls just want
> access to IWebBrowser to Navigate() somewhere else or check the current page
> URL. I haven't seen a control which walks the DOM, but I suppose they must
> exist. In this instance I would suggest we document the limits of the support
> and not step over it.

I meant that pages embedding Active X plugins use the IE DOM from their script
tags and event handlers; not that plugins commonly use IDOMWhatever interfaces
from their compiled code.  Is it not the case that pages wanting to script
Active X plugins need to use IE DOM extensions?  The GeckoActiveXObject vs.
ActiveXObject notwithstanding?

What pages embedding WMP work as-is today in a Mozilla build that includses the
built npmozax.dll and the two .js files?  Can someone name a few top sites?  It
still is not clear to me that any sites other than those already evangelized by
Netscape's TEDS team will work.
 
/be
> Concerning platform specific technology, I am in favour of not encouraging the
> widespread adoption of ActiveX.

What you say is largely irrelevant.  It's what you do that matters.

In other words, distributing the ActiveX plugin will lead web authors to think
that what they're doing is portable.  After all, many of them probably only have
access to one platform to test on, and if it works on IE and Mozilla on that
platform, then it must be portable.
So I'm personally not in favor of shipping Active X support in Mozilla builds,
but hyatt made an impassioned argument that too many Windows-oriented sites
(gamespot, others) look broken without WMP support.  Again, we must be sure
these sites will work without change if we just ship the support dll and js
files.  If that's not the case, then we need evangelism bugs.

But if many of these WMP-embedding sites start working without change, then the
argument hyatt makes goes like this: we have to win IE users over to Mozilla
products such as Firebird.  We can't afford to be pure; we are playing catch up
(taking the high road leads to pure loss of market share).  Plus, our market
share is so small, we are not likely to increase the presence of Active X
plugins on the web significantly by supporting just WMP.

dbaron, you may recall that WMP dropped NPAPI support; MS was playing hardball,
but Netscape gave MS an opening by dropping LiveConnected plugin support in the
new Mozilla world (Netscape 6 and higher).  The scriptable NPAPI extension we
now provide is used only by a handful of plugin vendors (Arun, please correct me
if I am wrong), and the MS WMP team will not use it.  So, it could be argued
that WMP support is a special case.

I personally don't like WMP, and I am against spreading Active X support.  But
drivers will have to argue and vote, or otherwise come to an agreement on what
to do here.  It seems to me if the question is one of supporting WMP only (and
no other clsids in the whitelist), then my personal opinion could and perhaps
should yield to the "WMP is a special case" counterargument.

/be
Interestingly, a guy just showed up on #mozilla asking for ActiveX support to
use on his intranet.

One additional reason to NOT enable ActiveX for the Internet is that it
uncomfortably increases our security exposure. (Even with whitelisting -- recall
the recent WMP vulnerability in parsing MIDI files.) Always-installed third
party plugins are a TCB that we cannot inspect or fix.

However, I think the argument for enabling ActiveX for intranets is pretty
strong. We could whitelist IP addresses in the private IP space. And, if we ship
the ActiveX infrastructure, then individual clueful users can turn it on for the
Internet if they really need it.

How about we just consider the question of whether we should turn this on for
intranets? Is anyone strongly opposed to that?
> then my personal opinion could and perhaps
> should yield to the "WMP is a special case" counterargument.

Yes -- please let's collectively eat humble pie on this one.  It is absolutely
the right thing to do.  Note that portability of any web site that particularly
targets WMP (argument in Comment 19) is irrelevant -- even my contacts at Yahoo
acknowledge that WMP is not a strong product on Mac (and wondered whether our
support within Gecko of WMP extended to Mac).  WMP and Windows are closely bound
-- other platforms don't matter.  Portability, therefore, doesn't matter here.

Brendan asks for examples of sites that work out of the box with WMP support. 
MTV Music is a good one (but largely deploys Real to browsers like Netscape 7.1
-- however their WMP code will work also), and more than one site from my
favorite alternative record labels (sure, I'll out myself as a fan: audio clips
on http://www.outcaste.com/ just started working, largely because of
Gecko-ignorant code deployed by the page authors).  But what's more important
than the few and far between examples is the fact that it is EASY to port IE web
pages that support WMP to Gecko.  The lion's share of issues are namespacing
issues, and with minimal effort, they can support a site. The details of how to
support the control are adequately supplied here on DevEdge:
http://devedge.netscape.com/viewsource/2003/windows-media-in-netscape/
Note that web page developers are very interested in this subject matter, thus
suggesting that evangelism is a feasible prospect -- I continue to get e-mail
from the DevEdge Feedback aliases on this subject matter (which I no longer have
the bandwidth to answer for obvious reasons).  Mozilla Foundation should grab
this article (and others on DevEdge) and host them where possible.

Comment 6 suggests that all sites that use WMP use ActiveXObject -- this is not
necessarily true.  While it is true that sites that use ActiveX use
ActiveXObject as the constructor, most sites simply using WMP use an OBJECT
element, then script it.  And that's really one of the winning propositions here
if we support WMP.  In fact, Microsoft's WMP Series 9 SDK hardly counsels the
use of ActiveXObject at all, favoring OBJECT element usage in conjunction with
scripting calls.  The DevEdge article provides a synthesis of all this.

Support WMP on Windows.  It will help, since I was unable to cement the
propagation of the scripting portion of the NPAPI with Microsoft's WMP team (who
used Java instead).  Plugins that do use it are Macromedia Flash, ViewPoint,
Cult3D, and other products that I can't discuss here yet.  Real uses XPCOM.

> WMP and Windows are closely bound-- other platforms don't matter. 
Portability, > therefore, doesn't matter here.

You're neglecting the fact that the behavior of user agents influences the web. 
(I also think people often underestimate the influence of Mozilla -- many web
developers have significant respect for its standards support and thus test in
it despite low market share.)

If we start supporting platform-specific technology on Windows, that will
increase the prevalence of these Windows-specific formats on the web and hurt
our users on other platforms (and hurt the Web).
The primary reason I would like to see this enabled is that sites geared towards Windows-only 
users make the assumption that they can deploy Windows-specific technology. A primary example 
is gaming sites.  The video game market is a Windows market, and when users go to video game 
sites, they are Windows users, plain and simple.  They aren't Linux users, and they aren't Mac 
users.  Enabling WMP on those sites does not hurt Linux/Mac users, since these sites were not 
targeted at Linux/Mac users to start with.

WMP is going to continue to be used, and IMO all we will accomplish by not supporting it is to lock 
ourselves out of sites that could otherwise be made to work on Windows.
Web sites that are only relevant to Windows users are a tiny portion of the web.
 I think the gain to our Windows users from being able to access such sites
would be smaller than the loss to our Mac and Linux users from the reduction in
support for non-WMP formats on sites that aren't relevant only to Windows users.
I guess the point of contention is that we disagree on how much influence
Mozilla supporting (or not supporting) WMP is going to have on these sites.  I
personally think that those sites who want to use WMP will do so with or without
Mozilla, and that our decision will have a negligible impact on the number of
sites that use it. Hence my desire to enable it, since all I see from not
supporting it is that we lock ourselves out of sites we could otherwise access
on Windows.



Arun: you wrote "But what's more important than the few and far between examples
is the fact that it is EASY to port IE web pages that support WMP to Gecko", but
I wonder how many will port just to get Netscape 7.1 and Mozilla (if we enable
it) support.

Can you give a count of pages that work now in 7.1?  How about a count of pages
that could work with a few tweaks, no major IE DOM => standard DOM rewrites?

/be
Comment 15: "Web sites that are only relevant to Windows users are a tiny
portion of the web."

Please revisit this claim in light of MediaMetrix data.  Some of this continues
to be available behind the NSCP/AOl firewall: http://evangelism.netscape.com/ .
 Furthermore, I would strongly counsel qualifying this claim with the fact that
the *actual number of sites* may be a tiny portion of the web in terms of
*number of sites* but NOT in terms of *numbers of visitors*.  Example:
launch.yahoo.com and broadcast.yahoo.com attract much of the yahoo.com userbase,
but they are only two sites.

Comment 17: Brendan -- alas, jjmata's documents inside the NSCP/AOL firewall
can't easily be found anymore, and they would help answer your questions :-( . 
But Ashish Bhatt kept good QA records, and knows exactly the DOM specifics of
all the sites he worked with (and of course, how many were important to the now
disbanded X-Team).  I'll CC Ashish.


How are launch.yahoo.com and broadcast.yahoo.com only relevant to Windows users?
 It may be that they only work on Windows, but that doesn't mean that users on
other platforms wouldn't be interested if cross-platform technology were used.
Comment #19 is best directed to the suits at yahoo.com, but permit me to give my
impression of them: "what's your market share?  Come back when you have enough
to make it worth our while to spend ~50-100K on developing and deploying yet
another  plugin glue layer."

It is conceivable to me that we can't gain market share only by being
cross-platform.  We may have to support some Windows-only things in order to
grow our market share to the point where we can influence the suits.  I think
drivers should take this into account in deciding this issue, and in developing
a longer term strategy for gaining market share without helping the dominant
monopoly and trapping ourselves into smoking on its tailpipe.

/be
> We may have to support some Windows-only things in order to
> grow our market share to the point where we can influence the suits.

But what will we use to influence them?  If we support Windows-only things, our
Windows market share won't help convince them to move to the cross-platform
equivalents, since whatever-it-is will work fine on Windows Mozilla.  And
supporting Windows-only features won't help our non-Windows market share -- it
can only hurt, really.
> But what will we use to influence them?

That is a topic for another bug, and another day, but it obviously can't be just
the compatibility with cross-platform and platform-specific web standards.  We
have to innovate.

Riding the rising Linux tide is necessary, but not sufficient, because one of
these years, Longhorn will ship and try to move the goalposts on the platform
game.  Why shouldn't an alliance of platform and tool vendors, and open source
projects, beat MS to the next "new new thing"?

/be
I agree that ActiveX is a potential can of worms and I do not want to promote it
as the primary means of extending behavior in Mozilla, however considering our
plug-in story, we do not currently have a workable technology with which to
replace it. 

Our plug-in history has been one of a moving target that has been undocumented
and continually changing which has resulted in at least one vendor of stopping
plug-in development for us. Promoting the cross-platform plug-in approach should
be our long range goal. Only when we support plug-in developers to easily create
cross-platform plug-ins for Windows, Mac, Linux and *nix will we be able to
discourage the development of platform specific code.

I do not think we can completely ignore ActiveX on Windows however. ActiveX on
Windows is a stable, well-documented technology which is backwardly compatible
over a range of OS's and browser versions and which is widely used. Telling
companies to not use such a widely available basic technology supported by
90%-100% of their users and to use instead the moving target of our plug-in
support is a losing proposition.

I think the ActiveX positions can be listed as

1. do not support ActiveX at all
2. support ActiveX WMP only
3. support only a whitelisted set of ActiveX Controls
4. support ActiveX fully on a limited 'intranet' set of IP addresses
5. support ActiveX fully everywhere.

I think we should allow each of these options on a configurable basis that can
be customized by the user or by a company wide customization and configuration
kit. We would ship with the default of the safest approach which would be 1 or 2.

And of course, we should get our plug-in story settled so that a plugin
developed for Mozilla today will still work for Mozilla tomorrow.
Speaking of backwards compatiblity. While mozilla.org hasn't taken pride in
maintaining backwards compatibility for anything (images, plugins, idl) [with
the possible exception of js], I think we need to consider what expectations
content providers who use activex will expect of us if we choose to support it
for a single version. Will they expect us to continue to support it for all
future versions of mozilla (at least 1.x for x>=5).

If we release 1.5 with ActiveX and then think we have a better story for 1.6
(well, 1.8) we will probably not be able to sell people on supporting it and
will almost certainly be stuck supporting ActiveX for the life of the 1.x
series. We already have a few misfires in this arena, we don't need more.
Whatever message we eventually select will have to compete with all of the
previous messages we've offered (NPAPI, LiveConnect, XPCOM, ActiveX, whatever
others I've forgotten).
I'm going to recommend installation of an ActiveX support as an option in the
installer (off by default).  

Working with a company right now, and using Mozilla.  Built in support would
make it more attractive.
I'm not sure which side to take. It seems to be a reasonable compromise that 
shipping mozilla on Win32 with ActiveX off by default that can be turned on
either at the installation time or at run time. comment #23). Below is just an
anecdotal (not very strong) 'support' for my position

> Comment 15: "Web sites that are only relevant to Windows users are a tiny
> portion of the web."

  I agree with that, but there are so many web sites (that are relevant to all
regardless of our desktop platform) that don't work without ActiveX support in 
Korea (arguably the most wired nation with Win32 dominating to the degree that
can't be paralled by any other place. I regard it as a 'shame', but sadly it's
the reality). A couple of months ago when I met a well-known Linux hacker in
Korea, I was asked whether I use Linux as my desktop OS. What a question from a
Linux hacker/evangelist !! Having worked in Korea for a couple of weeks or so, I
realized why he asked the question. I can do hardly anything on Linux. Internet
banking and most government agency web sites use proprieatary Win32 only
security checking systems with ActiveX instead of Java and https. Virtually all
live TV broadcasting and video-on-demand sites exclusively use WMP and ActiveX.
 I wrote several emails to protest this urging them to use XP technologies, but
in the meantime I'm seriously considering buying a VMware (to avoid constantly
rebooting my computer to Win32) or a similar program.    
Any chance anybody could take a decission here?

My employee just deployed a site with a Media Player embeded and no Mozilla
support:(
Henrik: can you try it out yourself?  It doesn't sound hard to configure Mozilla
with the extra .dll and two .js files, and it would help if you could say "it
just works" -- that makes it easier for others to follow, proving that the
support is ready to enable by default.

/be
brendan: this bug seems to be entirely political.

I don't see how the working state of the activex plugin hosting relates to
the resolution of this bug.

If you disagree, could you please explain how/why?

Or is your comment meant to indicate that drivers feel adding support for
ActiveX to mozilla for windows is a fait a compli?
Assignee: adamlock → drivers
timeless: settle down.  We host the Active X code, we want to know that it
works, even if it's off by default.  Otherwise we shouldn't host it.  Get it?

/be
(No quibbles about bugs, we host buggy code -- so does every open source
project. What I would like to know is, can users and distributors easily add the
.dll and the two .js files, and get working WMP?)

Just wanted to chime in here and bring in the feedback I heard during my trip to
Korea last week: the lack of Windows Media Player support in Mozilla is one of
the top 2 things preventing Mozilla adoption in Korea (the other one being NPKI,
a Korean encryption algorhythm used by all the financial institutions that's not
(yet) available on Mozilla).  This reenforces Jungshik's comment #26.  
Thanks, bart, for chiming in. Can we make up our mind here? 
brendan, I can assure you that it works with web pages that do not use
non-standard MSIE-specific DOM. 
Marketing product differentiation idea: I'd rather see WMP enabled by default in
Firefox, now that we are nearing 1.0.  If that aligns with the interests of
users (SeaMonkey users hate Active X or other MS proprietary junk, more than
Firefox users), great.

In any event, I've filed bug 247980 for Firefox supporting WMP.  This bug needs
other drivers' input.  I'll mail them.

/be
QA Contact: dunn5557 → activex
The ActiveX embedding API was removed in bug 662023 and friends, making this INVALID.

[Filter bugspam on activexinvalid]
Assignee: drivers → nobody
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → INVALID
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: