Closed Bug 133818 Opened 18 years ago Closed 18 years ago
Conditionally ship Active
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.
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 email@example.com, 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)
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.
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
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
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-
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-
Test for weird flag combos now generates a build error
Attachment #106015 - Attachment is obsolete: true
Attachment #106023 - Flags: review+
Comment on attachment 106023 [details] [diff] [review] Patch 3 Hi Brendan, can you sr this? Thanks
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?
You need to log in before you can comment on or make changes to this bug.