Passing --disable-activex to configure used to simply disable building the activex control in embedding/browser/activex. Now, it causes the following error: configure: error: Cannot enable ActiveX scripting support when ActiveX support is disabled. There should be an option to disable building the activex control independent of any other options for IDispatch and the activex plugin. I think those are both controlled by --disable-activex-scripting, so I'm thinking we can just restore --disable-activex to mean "don't build the activex gecko wrapper".
We're still working on this in bug 203362 I believe, but it wasn't reopened, so maybe this is a better place to handle that.
Created attachment 122446 [details] [diff] [review] Patch Patch again
Created attachment 122447 [details] [diff] [review] Patch again Third time lucky...
Comment on attachment 122447 [details] [diff] [review] Patch again Requesting an r= on this please
Comment on attachment 122447 [details] [diff] [review] Patch again You're still using the plugin variable to test whether to build the control. And since you removed MOZ_NO_ACTIVEX_SUPPORT from autoconf.mk.in, it will never be set so the test in embedding/browser/Makefile.in will fail and activex will never be built. How does this patch fit in with our current nightly automation setup? Since we use the same base configuration for all builds, how will the plugin ever get built w/o tainting the original tree?
Created attachment 122500 [details] [diff] [review] Updated patch Fixes typo, adds missing makefile. The patch deliberately does not build the plugin but enables the scripting. Anyone who wants to build the plugin has to set the --enable-activex-plugin flag for themselves or step in afterwards and build it manually. This means the plugin will no longer be built.
Comment on attachment 122500 [details] [diff] [review] Updated patch Requesting r on fixed version, thanks
With XPC_IDISPATCH_SUPPORT = @MOZ_ACTIVEX_SCRIPTING_SUPPORT@ is this still going to build the IDispatch code in Mozilla by default? It should be be building the IDispatch code even if we're not building and/or installing the plugin, so that if it's installed later it will be scriptable. (Sorry I'm still trying to figure out how the build machinery works).
MOZ_ACTIVEX_SCRIPTING_SUPPORT is defined to be 1 on Win32 platforms, so yes MOZ_ACTIVEX_SCRIPTING_SUPPORT and XPC_IDISPATCH_SUPPORT should both be defined in autoconf.mk by default. This means scripting support is built but the plugin (MOZ_ACTIVEX_PLUGIN_SUPPORT) is not. Previously it used to be built but not exported which didn't give much in return except to confuse everyone a great deal.
Comment on attachment 122500 [details] [diff] [review] Updated patch Requesting 1.4b approval for checkin. The new build switches resolve the confusion and ambiguity concerning what --disable-activex means and remove the need to build the plugin when it is not being used or exported.
Comment on attachment 122500 [details] [diff] [review] Updated patch a=asa (on behalf of drivers) for checkin to 1.4b.
Created attachment 122623 [details] [diff] [review] Updated patch Simplified again, this patch removes the --enable-activex-plugin switch, but builds the plugin when --enable-activex-scripting is defined. The plugin is still not exported unless MOZ_USE_ACTIVEX_PLUGIN is defined. This almost puts us almost back to square 1 concerning difficulties surrounding the plugin and not exposing it to dist/bin but needing to build. The patch should at least fix the confusion of what --enable-activex does.
Adam, I had forgotten about this bug. Is this still valid? Should you own this?
I'll take it for now. I might close it and reopen it if necessary.
Is this bug still valid? I'm not an expert, but since it is not working in Firefox, it should make FF builds a lot smaller if the control is not included.
MASS-CHANGE: This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614