Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 100008 - epiphany & galeon can't find plugins after upgrading to mozilla-1.7.10-r1
Summary: epiphany & galeon can't find plugins after upgrading to mozilla-1.7.10-r1
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Highest major (vote)
Assignee: Mozilla Gentoo Team
Depends on:
Reported: 2005-07-23 03:54 UTC by Vaclav Slavik
Modified: 2005-08-02 13:32 UTC (History)
6 users (show)

See Also:
Package list:
Runtime testing required: ---

This patch adds /usr/lib/nsplugins and /usr/lib/nsbrowser/plugins to the search path for plugins. (epiphany-1.6.4-nsplugins.patch,599 bytes, patch)
2005-07-24 09:03 UTC, James Lee
Details | Diff
plugin path patch for Galeon 1.3.21 (galeon-1.3.21-nsbrowser-plugin-path.diff,716 bytes, patch)
2005-07-26 08:40 UTC, Christian Birchinger (RETIRED)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Vaclav Slavik 2005-07-23 03:54:25 UTC
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
mozilla-launcher-1.41 does.

Unfortunately, Galeon doesn't use mozilla-launcher, so it doesn't fix Galeon
(or, I presume, Epiphany).

Reproducible: Always
Steps to Reproduce:
1. Run Galeon
2. Open about:plugins URL
Comment 1 foser (RETIRED) gentoo-dev 2005-07-23 11:03:27 UTC
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.
Comment 2 James Lee 2005-07-24 09:03:52 UTC
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.
Comment 3 foser (RETIRED) gentoo-dev 2005-07-25 03:45:08 UTC
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.
Comment 4 James Lee 2005-07-25 13:16:12 UTC
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.
Comment 5 Christian Birchinger (RETIRED) gentoo-dev 2005-07-26 08:40:24 UTC
Created attachment 64356 [details, diff]
plugin path patch for Galeon 1.3.21

I've did this patch for my own machine.
Comment 6 Gergan Penkov 2005-07-27 07:25:16 UTC
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.
Comment 7 Gergan Penkov 2005-07-27 09:24:10 UTC
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.
Comment 8 Gergan Penkov 2005-07-27 09:27:05 UTC
P.S. the same affect mozilla, simply changing the mozilla-firefox with mozilla
where appropriate should solve the problem.
Comment 9 Andy Dustman 2005-07-30 19:31:10 UTC
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
total 20
lrwxrwxrwx  1 root root    42 Jul 30 22:27 flashplayer.xpt ->
lrwxrwxrwx  1 root root    40 Jul 30 22:27 ->
lrwxrwxrwx  1 root root    44 Jul 30 22:27 ->
lrwxrwxrwx  1 root root    41 Jul 30 22:27 libmozsvgdec.a ->
lrwxrwxrwx  1 root root    42 Jul 30 22:27 ->
lrwxrwxrwx  1 root root    42 Jul 30 22:27 ->
-rwxr-xr-x  1 root root 19500 Jul 24 05:56
lrwxrwxrwx  1 root root    44 Jul 30 22:27 ->
lrwxrwxrwx  1 root root    45 Jul 30 22:27 mplayerplug-in.xpt ->
lrwxrwxrwx  1 root root    35 Jul 30 22:27 ->

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.
Comment 10 Gergan Penkov 2005-07-31 12:59:01 UTC
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:)
Comment 11 Aron Griffis (RETIRED) gentoo-dev 2005-08-02 13:30:47 UTC
This issue should be fixed with these recent releases.  Please try and re-open
this bug if the problem persists:

Comment 12 Aron Griffis (RETIRED) gentoo-dev 2005-08-02 13:32:20 UTC
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 (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
handled correctly.