Status

SeaMonkey
Build Config
RESOLVED INCOMPLETE
15 years ago
9 years ago

People

(Reporter: Brian Ryner (not reading), Assigned: Adam Lock)

Tracking

Trunk
x86
Windows XP

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 4 obsolete attachments)

4.02 KB, patch
Details | Diff | Splinter Review
(Reporter)

Description

15 years ago
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".

Comment 1

15 years ago
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.
(Assignee)

Comment 2

15 years ago
Created attachment 122445 [details] [diff] [review]
Patch

Patch, simplified from 203362
(Assignee)

Comment 3

15 years ago
Created attachment 122446 [details] [diff] [review]
Patch

Patch again
Attachment #122445 - Attachment is obsolete: true
(Assignee)

Comment 4

15 years ago
Created attachment 122447 [details] [diff] [review]
Patch again

Third time lucky...
Attachment #122446 - Attachment is obsolete: true
(Assignee)

Comment 5

15 years ago
Comment on attachment 122447 [details] [diff] [review]
Patch again

Requesting an r= on this please
Attachment #122447 - Flags: review?(seawood)
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?
Attachment #122447 - Flags: review?(seawood) → review-

Comment 7

15 years ago
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.
Attachment #122447 - Attachment is obsolete: true
(Assignee)

Comment 8

15 years ago
Comment on attachment 122500 [details] [diff] [review]
Updated patch

Requesting r on fixed version, thanks
Attachment #122500 - Flags: review?(seawood)
Attachment #122500 - Flags: review?(seawood) → review+

Comment 9

15 years ago
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).
(Assignee)

Comment 10

15 years ago
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.

(Assignee)

Comment 11

15 years ago
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.
Attachment #122500 - Flags: approval1.4b?

Comment 12

15 years ago
Comment on attachment 122500 [details] [diff] [review]
Updated patch

a=asa (on behalf of drivers) for checkin to 1.4b.
Attachment #122500 - Flags: approval1.4b? → approval1.4b+

Comment 13

15 years ago
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.
Attachment #122500 - Attachment is obsolete: true

Comment 14

15 years ago
Adam, I had forgotten about this bug. Is this still valid? Should you own this?
(Assignee)

Comment 15

15 years ago
I'll take it for now. I might close it and reopen it if necessary.
Assignee: dbradley → adamlock

Comment 16

14 years ago
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.
Product: Browser → Seamonkey

Comment 17

9 years ago
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
Status: NEW → UNCONFIRMED

Updated

9 years ago
Status: UNCONFIRMED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.