Closed
Bug 266750
Opened 20 years ago
Closed 20 years ago
Add --disable-plugins build option
Categories
(SeaMonkey :: Build Config, defect)
SeaMonkey
Build Config
Tracking
(Not tracked)
RESOLVED
FIXED
mozilla1.8alpha5
People
(Reporter: cls, Assigned: cls)
References
Details
(Keywords: fixed-aviary1.0)
Attachments
(1 file)
(deleted),
patch
|
benjamin
:
review+
mscott
:
approval-aviary+
|
Details | Diff | Splinter Review |
Some of our applications like Thunderbird or Nvu have no need for plugin
support. Besides reducing the footprint of the apps, disabling plugin support
avoids the issue of unexpected plugin usage as in bug 223600.
Attachment #163876 -
Flags: review?(bsmedberg)
Comment 2•20 years ago
|
||
I don't mind this patch for embedders, but I *don't* want it to be used by
toolkit apps. Plugin support is an integral part of the toolkit. If necessary,
we should turn plugins off with a pref.
It can't be that integral if it's this easy to disable. :-P I know this
disrupts the 'single GRE for all toolkit apps' idea but it seems like we were
well on our way to that anyway given the disparity between the ff & tb
mozconfigs. And this isn't a completely invasive patch like the --disable-oji
one. This patch just disables the building of the runtime components
(shared/static lib & xpts). Applications still have knowledge of plugins; they
just can't instantiate any of the classes. (I should remove that unused
MOZ_PLUGINS define too.)
Comment 4•20 years ago
|
||
please file a follow-up bug to provide an alternative runtime solution (using
prefs or otherwise). the rough goal is to move toward basing ffox & tbird on a
common xulrunner base around the 1.5 time frame, and this then becomes yet
another thing to unfork :)
Will bug 189378 do or do we need to file one on each toolkit app since
apparently SeaMonkey's mailnews already has something similar? See also bug 218877 .
Comment 6•20 years ago
|
||
> Will bug 189378 do ...
seems fine to me.
fwiw we'll probably use this patch in our gecko derivative whether it makes
itself into mozilla proper or not. cls: thanks for the patch :).
it also was more integral not too long ago.
Updated•20 years ago
|
Attachment #163876 -
Flags: review?(bsmedberg) → review+
Attachment #163876 -
Flags: approval-aviary?
Comment 8•20 years ago
|
||
I just checked this into the aviary 1.0 branch. Let me know if you want me to be
the one to check it into the trunk too Chris. Thanks again!
Keywords: fixed-aviary1.0
Updated•20 years ago
|
Attachment #163876 -
Flags: approval-aviary? → approval-aviary+
I just checked in the patch on the trunk sans AC_DEFINE(MOZ_PLUGINS). I removed
that chunk from the aviary-1.0 branch as well.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.8alpha5
Comment 10•20 years ago
|
||
Does this mean that plugin support will be disabled in Thunderbird nightly
standard builds?
If so, it is a real 'show stopper' for newsgroups now using the crescendo sound
plugin. Many have considered our ability to use this plugin the only real
'progress' for the multimedia user in quite some time.
news://secnews.netscape.com:563/netscape.test.multimedia
What is the objection to disabling plugins by default pref in all-thunderbird.js
as it is currently.
Comment 11•20 years ago
|
||
we've never supported plugins
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•