246672 - Firefox should search for plugins in /usr/lib/mozilla/plugins

Status: RESOLVED WORKSFORME

(Core Graveyard :: Plug-ins, defect, P2)

Description

[Christopher Aillon (sabbatical, not receiving bugmail)]

Red Hat and the Fedora Project ship browser plugins in /usr/lib/mozilla/plugins.
 (I also have evidence which leads me to believe that SuSE and Mandrake follow
suit though I can't personally confirm this).

If a Red Hat or Fedora user downloads any official mozilla.org build, they will
"lose" their plugins because those builds don't look for plugins in the de facto
linux standard plugin path.  Mozilla.org released builds should look for plugins
in /usr/lib/mozilla/plugins

Comment 1

[Mike Connor [:mconnor]]

SuSE uses /usr/lib/browser-plugins, according to Hendikins.

someone on FC2 reported the plugins were in mozilla-1.6/plugins, and
mozilla/plugins was empty.

Comment 2

[David Hallowell]

Just specify a directory, place it in the release notes and plugin documentation
and then the Linux distros can standardise on that location. Of course the
per-app and per-user plugins should still work too.

It'd be a good idea to agree with Opera and the KHTML devs the path of the
standard plugin location particularly work is underway to improve the plugin
interface.

MacOS X already has a standard plugin location.

I also think Windows users should have a common location for plugins - this
would be better than the current situation of installers like flash having to
make a copy of each plugin for every app installed that uses NPapi plugins
(Opera, Netscape, Mozilla, Firefox, etc) - although this may want to wait until
the updated plugin api is implemented so we know plugins in that location should
be compatible,

See bug 76015

Comment 3

[Christian :Biesinger (don't email me, ping me on IRC)]

(In reply to comment #2)
> the updated plugin api is implemented so we know plugins in that location should
> be compatible,

uh, all browsers who support the "old" plugin api will support the "new" one
(except scriptability), and all that support the "new" one will work fine with
plugins using the "old" one (possibility without scriptability)

Comment 4

[logan]

How about a /usr/local/lib/mozilla/plugins as well?

Comment 5

[Christopher Aillon (sabbatical, not receiving bugmail)]

Attachment: Fedora's 'mozilla' script

This is what we use to do this.

Comment 6

[logan]

Attachment: firefox patch v1

How about something like this?

Defaults:
$dist_bin/plugins:/usr/lib/mozilla/plugins:/usr/local/lib/mozilla/plugins

Comment 7

[logan]

Attachment: patch v1.1

doh, left an echo in there :P

Comment 8

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

I don't know why I got this bug, but I'm sure it was a mistake!

Comment 9

[Anthony Lanni]

Hi!  I'm seeing this same issue.  I've got the following OS:

Linux winchester 2.6.9-67.0.1.ELsmp #1 SMP Fri Nov 30 11:57:43 EST 2007 x86_64 x86_64 x86_64 GNU/Linux

running 

Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.0.1) Gecko/2008071010 Red Hat/3.0.1-1.el4 Firefox/3.0.1

I took a nice hard look at /usr/bin/firefox, which figures out architecture, install paths, etc. and then sets the env variable MOZ_PLUGIN_PATH to:

/usr/lib/mozilla/:/usr/lib/firefox-3.0.1/

which looks correct.  Unfortunately it doesn't apparently actually use that variable, because Firefox reads the plugins directory in /usr/lib/firefox/3.0.1
but not the /usr/lib/mozilla/plugins directory.

As a workaround I linked one to the other, but that's not tenable as a long term enterprise solution.

thx
    anthony

Comment 10

[Robert Strong (they/them - no direct email)]

The code that looks for plugins is Core -> Plugins and not OS Integration... changing components