Closed
Bug 204292
Opened 22 years ago
Closed 16 years ago
Fix --disable-activex
Categories
(SeaMonkey :: Build Config, defect)
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
People
(Reporter: bryner, Assigned: adamlock)
Details
Attachments
(1 file, 4 obsolete files)
4.02 KB,
patch
|
Details | Diff | Splinter Review |
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•22 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.
Patch again
Attachment #122445 -
Attachment is obsolete: true
Third time lucky...
Attachment #122446 -
Attachment is obsolete: true
Comment on attachment 122447 [details] [diff] [review]
Patch again
Requesting an r= on this please
Attachment #122447 -
Flags: review?(seawood)
Comment 6•22 years ago
|
||
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-
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
Comment on attachment 122500 [details] [diff] [review]
Updated patch
Requesting r on fixed version, thanks
Attachment #122500 -
Flags: review?(seawood)
Updated•22 years ago
|
Attachment #122500 -
Flags: review?(seawood) → review+
Comment 9•22 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•22 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•22 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•22 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•22 years ago
|
||
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•22 years ago
|
||
Adam, I had forgotten about this bug. Is this still valid? Should you own this?
Assignee | ||
Comment 15•22 years ago
|
||
I'll take it for now. I might close it and reopen it if necessary.
Assignee: dbradley → adamlock
Comment 16•21 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.
Updated•20 years ago
|
Product: Browser → Seamonkey
Comment 17•16 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•16 years ago
|
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•