Closed Bug 266750 Opened 20 years ago Closed 20 years ago

Add --disable-plugins build option

Categories

(SeaMonkey :: Build Config, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
mozilla1.8alpha5

People

(Reporter: cls, Assigned: cls)

References

Details

(Keywords: fixed-aviary1.0)

Attachments

(1 file)

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.
Attached patch v1.0 (deleted) — Splinter Review
Blocks: 223600
Attachment #163876 - Flags: review?(bsmedberg)
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.)
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 .
> 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.
Attachment #163876 - Flags: review?(bsmedberg) → review+
Attachment #163876 - Flags: approval-aviary?
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
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
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.
we've never supported plugins
Product: Browser → Seamonkey
Blocks: 272064
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: