Browser plugins no longer work in Galeon after upgrading to the latest Mozilla
in Portage. "about:plugins" URL shows empty list.
Yesterday, the same problem existed in Firefox or Mozilla itself, but
mozilla-launcher-1.41 apparently fixes it. From its changelog, it's clear the
nsplugins patch is broken and you have to set MOZ_PLUGIN_PATH, so this is what
Unfortunately, Galeon doesn't use mozilla-launcher, so it doesn't fix Galeon
(or, I presume, Epiphany).
Steps to Reproduce:
1. Run Galeon
2. Open about:plugins URL
I can confirm epiphany shows similar behaviour and that this needs a proper fix
I also noticed mplayerplug-in doesn't compile with mozilla 1.7.10 . This is all
not so good for a stable pack.
Created attachment 64203 [details, diff]
This patch adds /usr/lib/nsplugins and /usr/lib/nsbrowser/plugins to the search path for plugins.
Attached is a patch to fix the problem with Epiphany. A similar patch will
have to be made for Galeon most likely.
No I think this should be fixed @ the source and that is mozilla finding it's
own default plug-in dir without setting environment vars.
Well if you look at mozilla-firefox-1.0.6-nsplugins.patch, that is exactly how
Mozilla and Firefox in Portage are doing it, modifying the MOZ_PLUGIN_PATH,
which, evidently, doesn't work with its embedding library.
Created attachment 64356 [details, diff]
plugin path patch for Galeon 1.3.21
I've did this patch for my own machine.
After some upgrade in the last 48 hours neither galeon, nor epiphany are working
for me, it seems that firefox removes some lines from /etc/env.d, which set the
essential paths, for galeon and epiphany (for example MOZILLA_FIVE_HOME).
I have commented also on bug# 99621 and I think the resolution to all these
problems is a mozilla-config tool, which should behave in the similar way to
java-config (interchanging the file in env.d to the correct one, which defines
the needed environment-variables). And not hardcoding this in galeon or epiphany.
The problem is not in mozilla also, because it is in the way we define the
environment settings, why should we create possible collisions with exporting
two ldpaths for mozilla and mozilla-firefox - they are defining the same
libraries, and it is logical that in this case no one knows which one will be
called. There are two soultions to this: the first is using some tool, as I said
to intechange the things in /etc/env.d, the second is more elegant we should
link the things, which use mozilla or mozilla-firefox with runpath and/or rpath
field, which ensures the correct resolution and does not need change in the
source file, but in the make-file.
corrections, it is not a problem in galeon or epiphany, and my earlier comment
should not be taken very seriously (the rpath/runpaths are set correctly):) .
after some explorations:
1. my bug is corrected with rebuilding (because the rpaths were
2. the bug explained in this bug could be corrected with removing the
/usr/lib/mozilla-firefox/plugins and linking it with
ln -s /usr/lib/nsbrowser/plugins /usr/lib/mozilla-firefox/plugins
to the plugins directory. It is a simple bug in mozilla-firefox, the ebuild
should remove the /usr/lib/MozillaFirefox directory and probably link it to
/usr/lib/mozilla-firefox, and remove /usr/lib/mozilla-firefox/plugins and make
instead a link to /usr/lib/nsbrowser/plugins.
I will test and try if all programs could function without the /etc/env.d,
because the idea of exporting two ldpaths which contain essentially equivalent
libraries is not a good idea.
P.S. the same affect mozilla, simply changing the mozilla-firefox with mozilla
where appropriate should solve the problem.
I re-emerged galeon (1.3.21) and it doesn't fix the problem. The workaround is
to use symbolic links:
chef plugins # cd /usr/lib/mozilla/plugins
chef plugins # ls
chef plugins # ln -s /usr/lib/nsbrowser/plugins/* .
chef plugins # ls -l
lrwxrwxrwx 1 root root 42 Jul 30 22:27 flashplayer.xpt ->
lrwxrwxrwx 1 root root 40 Jul 30 22:27 javaplugin.so ->
lrwxrwxrwx 1 root root 44 Jul 30 22:27 libflashplayer.so ->
lrwxrwxrwx 1 root root 41 Jul 30 22:27 libmozsvgdec.a ->
lrwxrwxrwx 1 root root 42 Jul 30 22:27 libmozsvgdec.la ->
lrwxrwxrwx 1 root root 42 Jul 30 22:27 libmozsvgdec.so ->
-rwxr-xr-x 1 root root 19500 Jul 24 05:56 libnullplugin.so
lrwxrwxrwx 1 root root 44 Jul 30 22:27 mplayerplug-in.so ->
lrwxrwxrwx 1 root root 45 Jul 30 22:27 mplayerplug-in.xpt ->
lrwxrwxrwx 1 root root 35 Jul 30 22:27 nppdf.so ->
Maybe the plugin ebuilds should be changed to use /usr/lib/mozilla/plugins
instead? Just a thought; I really don't know what the correct solution is.
It is not that easy, there are currently some 4 directories, in which the
plugins are installed ::)), and not only this, but if you install, say, opera
and want to use the plugins ?
It was better simply to delete /usr/lib/mozilla/plugins and link the directory
and not each plugin, because you would have to repeat this procedure after the
installation of a new plugin:)
This issue should be fixed with these recent releases. Please try and re-open
this bug if the problem persists:
Sorry, I didn't mean to be vague. To give a little more information, I fixed
the nsplugins patch last night. The nsplugins patch causes libxpcom.so (part of
mozilla) to search for the plugins in /usr/lib/nsbrowser/plugins as well as
/usr/lib/mozilla/plugins (or firefox, you get my drift). Multilib is also