Closed Bug 133818 Opened 18 years ago Closed 18 years ago

Conditionally ship ActiveX plugin

Categories

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

x86
All
defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED
Future

People

(Reporter: john, Assigned: adamlock)

References

Details

Attachments

(1 file, 6 obsolete files)

We should ship the ActiveX plugin by default on Windows.
Why would we do this?
So that we can run ActiveX controls in a default Mozilla build.

Why would we not do this?
The ActiveX plugin is already checked into the Mozilla source.

At this time, Netscape is not interested in supporting ActiveX.

However, Mozilla is free to choose otherwise.
Not only would it need to be built by default, in *any* case there needs to be a
Makefile.in in this directory so that it will build in gmake builds.  CC'ing Chris.
I thought that we already did this?  What's embedding/browser/activex ? FWIW, I
think Mozilla should follow Netscape's lead and avoid activex but that's my
paranoid speaking.

There are three activex related things under /embedding/browser/activex:

1. The Gecko activex control. We build and ship that already.
2. The plugin for hosting ActiveX inside Mozilla/6.x/4.x. We neither build nor
   ship this.
3. The activex control for hosting plugins (inside IE & VB apps etc.).
   We neither build nor ship this.

The functionality of the plugin for hosting activex controls (2) is very limited
so I don't think we should ship it, however I believe we should add 2 & 3 to the
build process at least to raise their profile a little.

In particular 3 is the only way at present that IE users and other ActiveX
programmers can embed plugins in their applications since MS dropped support in
IE 5.0 SP2.
.
Target Milestone: --- → Future
The plugin for hosting ActiveX is almost in a state to be included in the
regular build. I'll submit a patch to enable it.

Attached patch Patch (obsolete) — Splinter Review
Patch adds "plugins" to list of DIRS to build and fixes a small dependency
problem. Note, the activex branch where this makefile is situated only gets
built on Win32 do there is no need do further conditional checks of that
nature.

Reviews please?
All this needs is r=cls@seawood.org, per
http://www.mozilla.org/hacking/reviewers.html#exceptions -- cls, I'm paranoid
too but I think this patch should go in.

/be
ok, I can see how this would be usefull for certain uses like corporate
intranets and stuff.

Personally I think this should:
1.be built as part of a standard build
2.be included with mozilla
3.be turned off by default
4.be activatable via a pref
5.have an option where you can limit where mozilla will fetch activex controlls
from (so if your internal web server is at a certain IP or name, you can put
that name in the box and moz wont run any activex controlls from any other servers.
and 6.make it so that mozilla wont run any activex or vbscript from mail
messages at all

That means that most people dont even have to do anything, the only noticable
effect is a new dll in the mozilla folder.
Those that need activex can turn it on in prefs and can restrict access to those
servers that serve the activex they need (and that they trust not to feed them
bad code)
Attached patch Cleanup plugin/Makefile.in (obsolete) — Splinter Review
I cleaned up plugin/Makefile.in:
Made it objdir-aware. 
Removed unnecessary dependency rules
Made it parallel build (-jx) safe.
Attachment #97335 - Attachment is obsolete: true
I agree that at least 1-4 of comment #11 should be implemented before this goes
in because Gecko will currently always skip Netscape-style plugins when nested
inside ActiveX OBJECT tags when Adam's plugin is installed. Since not all
ActiveX controls work yet with the plugin, some sites may break.
Attached patch properly subst MOZ_SRC (obsolete) — Splinter Review
Attachment #97379 - Attachment is obsolete: true
Assigning Shrir as the default QA
QA Contact: cpratt → shrir
Here's an idea:

Currently, all plugins require a mime-type to be instantiated. The ActiveX
plugin registers for these mime types:
application/x-oleobject
application/oleobject
text/x-activescript

Gecko will currently *automatically* try to instantiate a plugin for
'application/x-oleobject' (or 'application/oleobject') whenever it sees OBJECT
tag with a CLASSID attribute. Since most ActiveX/Plugin tags are coded this way,
we'll always try ActiveX plugin first and almost never try the nested Netscape
plugin.

A possible solution is to turn off this automatic selection of the ActiveX
mime-type (or have it controled by pref, default off) based on CLASSID and
require HTML authors to explicity choose our plugin that gives ActiveX support
by specifying its mime type in the TYPE attribute, like is done for all other
plugins. Since this plugin is a handler for ActiveX controls and only works on
Windows, highly suggesting (requiring) HTML authors to use normal Netscape
plugin syntax by specifying a TYPE='application/x-oleobject' attribute sounds
petty natural. 

Thoughts?
to be clear:
the current state of the ActiveX plugin is indeed in a state where we should at
least be distributing it (registering it in the windows reg is another question
perhaps).

see http://www.iol.ie/~locka/mozilla/plugin.htm for more status.

in short there are at least two significant implementation issues that would
need to be resolved before the plugin is useful at large:

1. scriptability - currently very limited.
2. download/signature verification/install of components not already on the system

those are two big hurdles to overcome if anyone wanted to head toward full
functional support.
This particular patch should not be checked in until we have resolved the nested
plug-in issue. Please review Peter's comment above as to why this is necessary.
Depends on: 109082
Attached patch Slightly updated patch (obsolete) — Splinter Review
Patch contains all of Chris's changes, but modifies the copy-sources rule to
work properly.

I will check the changes into this makefile, but not the one above it so the
plugin will still not part of the build for the time being.
Attachment #97461 - Attachment is obsolete: true
Renaming bug. Plugin needs to be conditionally built & installed, depending on a
configure switch.
Summary: Ship ActiveX Plugin By Default → Conditionally ship ActiveX plugin
Attached patch Patch (obsolete) — Splinter Review
Patch adds --enabled-activex-scripting (default is off) and conditional
compilation of the plugin directory. I've also updated the application &
embedding Windows packages to include npmozax.dll if it is present.

Reviews please.
Attachment #98445 - Attachment is obsolete: true
Comment on attachment 105874 [details] [diff] [review]
Patch

Nitpicks:  can you make sure that the comment for the configure option lines up
with the rest of the descriptions in the ./configure --help output?  I believe
it starts on column 26.  

Also, the activex-scripting option needs to unset the
MOZ_ACTIVEX_SCRIPTING_SUPPORT variable whenever --disable is given. 

The OS_ARCH check in the Makefile.in isn't necessary as activex is only built
on win32.

And because people are showing a penchant for doing silly things, you may want
to add a check to make sure that someone didn't specify --disable-activex &
--enable-activex-scripting together.
Attachment #105874 - Flags: review-
Attached patch Patch with nits addressed (obsolete) — Splinter Review
Patch lines up the help, catches weird --disable-activex &
--enable-activex-scripting combination and unsets MOZ_ACTIVEX_SCRIPTING_SUPPORT
in the disable case. Also removed the NT arch test in the Makefile.in.
Attachment #105874 - Attachment is obsolete: true
Comment on attachment 106015 [details] [diff] [review]
Patch with nits addressed

Actually, I was thinking more along the lines of a build stopping error if
conflicting activex options were given:
if test -n"$MOZ_NO_ACTIVEX_SUPPORT" -a -n "$MOZ_ACTIVEX_SCRIPTING_SUPPORT";
then
AC_MSG_ERROR([Cannot enable activex scripting support when activex support is
disabled.])
fi
Attachment #106015 - Flags: review-
Attached patch Patch 3Splinter Review
Test for weird flag combos now generates a build error
Attachment #106015 - Attachment is obsolete: true
Comment on attachment 106023 [details] [diff] [review]
Patch 3

Hi Brendan, can you sr this? Thanks
Attachment #106023 - Flags: superreview?(brendan)
Comment on attachment 106023 [details] [diff] [review]
Patch 3

http://www.mozilla.org/hacking/reviewers.html#exceptions says r=seawood is
enough for build-file changes.

/be
Fix is checked in 
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
This is totally WRONG!!!  Is Mozilla to support propritary technologies now? I
was under the impression that one of the stated goals was that Mozilla was to be
totally cross platform. Now Mozilla is building in a technology which works with
only one platform. This is worng.

I thought one of the aims of the Mozilla project was to help support and ensure
the ideal that the internet remain platform/browser independent--that it didn't
matter which operating system, which berowser, or which hardware the user used
to access the internet. If the feature is added to the Windows version of
Mozilla is Mozilla saying the ideals of equal access to the internet for all
browsers, for all OSs and for all hardware no longer matters?  This is wrong!!! 
As far as I can tell from cvs log, the ActiveX plugin has been in the mozilla
tree since 1999. I think the patch only adds the ability to build the plugin via
a build Configurator option rather than an environment variable, but it's still
off by default.
Re: comment #29: Mozilla will not support ActiveX of any sort on Windows, while
I'm around.  Mozilla-derived products may, but complaints about derived product
plans don't belong in bugzilla.mozilla.org.

/be
Can someone tell me how to enable this feature?
Attachment #106023 - Flags: superreview?(brendan)
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.