[25416] in Athena Bugs
Re: mozilla plugin path overrides?
daemon@ATHENA.MIT.EDU (John Hawkinson)
Sat Jan 10 19:00:19 2004
Date: Sat, 10 Jan 2004 18:58:26 -0500
From: John Hawkinson <jhawk@mit.edu>
To: Greg Hudson <ghudson@mit.edu>
Message-ID: <20040110235826.GS818@multics.mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1073778726.32657.331.camel@error-messages.mit.edu>
cc: bugs@mit.edu
Errors-To: bugs-bounces@mit.edu
Greg Hudson <ghudson@MIT.EDU> wrote on Sat, 10 Jan 2004
at 18:52:07 -0500 in <1073778726.32657.331.camel@error-messages.mit.edu>:
> > I doubt there are many people who set MOZ_PLUGIN_PATH and expect it to
> > be appeneded to, so I doubt many would suffer.
>
> I do this, in order to get a newer flash plugin than the one we have
> installed. Obviously, I'm not concerned about my own welfare, but
> anyone who followed the same thought process will have done the same
> thing.
Hmm. I didn't realize that would work.
(Hmm, no, copying libnullplugin.so into a libflashplayer.so earlier
in MOZ_PLUGIN_PATH doesn't help; bummer).
> A more backwards-compatible, if less elegant solution, would be to
> invent a new variable name (MOZ_FULL_PLUGIN_PATH or something), and have
> it override the plugin path computed by the wrapper script if it's set.
Yeah, I thought about that and figured that the simpler patch was more
likely to be accepted. I'd be happy to respin the patch, but I'll assume
that's so trivial that you or Bob would rather do it yourselves (let me
know if I'm wrong).
> > p.s.: Arguably it's better to have all the plugins symlinked from
> > $HOME/.mozilla/plugins (though an @sys indirection, I guess), so
> > that users can decide which plugins they want all by themselves,
> > instead of being forced to accept the system plugins. I guess that
> > might make it more awkward to add a new plugin systemwide, though,
> > but it could be handled.
>
> Could be handled how?
By having the wrapper script check a list of plugins and create symlinks
to any new ones. Such a list could have dates so that it would not recopy
those users had rm'd. (I'm not sure this is a good archicture, but it
is certainly one way of solving the problem).
I guess a superior solution would be to build a UI infrastructure in
mozilla that would let me do what I want, namely control plugin
dispatching, both in general ("disable plugins") and on a per-web-site
basis ("only enable this plugin for that site")... I don't think this is
happening anytime soon though.
--jhawk