Note: There are a few cases of duplicates in user autocompletion which are being worked on.

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




13 years ago
5 years ago


(Reporter: Christopher Aillon (sabbatical, not receiving bugmail), Unassigned)


Bug Flags:
blocking-aviary1.0PR -
blocking-aviary1.0 -

Firefox Tracking Flags

(Not tracked)



(2 attachments, 1 obsolete attachment)

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 build, they will
"lose" their plugins because those builds don't look for plugins in the de facto
linux standard plugin path. released builds should look for plugins
in /usr/lib/mozilla/plugins
Flags: blocking1.0?
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.
Assignee: bugs → shaver
Flags: blocking-aviary1.0RC1+
Flags: blocking-aviary1.0?
Flags: blocking-aviary1.0-

Comment 2

13 years ago
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

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
(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)
Flags: blocking-aviary1.0PR-
Flags: blocking-aviary1.0PR+
Flags: blocking-aviary1.0-
Flags: blocking-aviary1.0+
Priority: -- → P2

Comment 4

13 years ago
How about a /usr/local/lib/mozilla/plugins as well?
Created attachment 155129 [details]
Fedora's 'mozilla' script

This is what we use to do this.

Comment 6

13 years ago
Created attachment 155131 [details] [diff] [review]
firefox patch v1

How about something like this?


Comment 7

13 years ago
Created attachment 155133 [details] [diff] [review]
patch v1.1

doh, left an echo in there :P
Attachment #155131 - Attachment is obsolete: true
Flags: blocking-aviary1.0+ → blocking-aviary1.0-
I don't know why I got this bug, but I'm sure it was a mistake!
Assignee: shaver → nobody
Assignee: nobody → darin


11 years ago
Assignee: darin → nobody

Comment 9

9 years ago
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


Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv: 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:


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.

The code that looks for plugins is Core -> Plugins and not OS Integration... changing components
Component: OS Integration → Plug-ins
Product: Firefox → Core
QA Contact: os.integration → plugins
Last Resolved: 5 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.