User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:71.0) Gecko/20100101 Firefox/71.0

Steps to reproduce:

1. Install plugins to the default path in Fedora 30 which is /usr/lib64/mozilla/plugins. For example install flashplugin.
2. Export "MOZ_PLUGIN_PATH=/usr/lib64/mozilla/plugins" and start firefox:

MOZ_PLUGIN_PATH=/usr/lib64/mozilla/plugins firefox

Actual results:

No flash plugin is listed in the "about:addons" page.
If the plugin is copied to /usr/lib/mozilla/plugins it is listed.

Expected results:

Plugins installed in /usr/lib64/mozilla/plugins should have been listed in the "about:plugins" page.

Hi, bug.report.tracker!

Thanks for your contribution!

I couldn't reproduce the described behavior in:

Ubuntu 18.04.3 LTS
Firefox 71.0 (64-bit)
Nightly 73.0a1 (2019-12-07)

On those 2 versions mentioned above, I could find the plugins inside about:plugins as you mentioned, but could be a Fedora specific problem so since I don't have a Fedora installation on my set up, I need to ask you to try this on a fresh profile with the latest nightly.

You can download Nightly from here: https://nightly.mozilla.org/

If you still have the issue please create a new profile, you have the steps here: https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles?redirectlocale=en-US&redirectslug=Managing-profiles#w_starting-the-profile-manager
support.mozilla.orgsupport.mozilla.org

Once you have all this information, please let us know so we can continue investigating.

Regards,

Have you actually tried setting MOZ_PLUGIN_PATH in your environment?

Please, try the following copy firefox plugins to any directory other than default, which is /mnt/loop/usr/lib/mozilla/plugins/ on Ubuntu x86_64.

Please, try the following:

1. Move firefox plugins to any directory other than default, which is /usr/lib/mozilla/plugins/ on Ubuntu x86_64.
2. Export MOZ_PLUGIN_PATH=<path to the new plugin directory>
3. See if the plugins are listed in firefox.

The problem is that flash plugin is installed to /usr/lib64 on Fedora, but firefox
assumes that plugins should be in /usr/lib. Setting MOZ_PLUGIN_PATH=/usr/lib64/mozilla/plugins/
has absolutely no effect. No plugins are listed unless they are copied to /usr/lib/mozilla/plugins/

The issue is easily reproduced on the nightly build as well. It's reproducible with any profile, including clean install, on both Fedora and Ubuntu.
Please, address the actual issue, which is the MOZ_PLUGIN_PATH environment variable has no effect.
Thanks,
B.

This seems to be intentional change of bug 1580282, which appears to break many distributions. In my distribution system provided plugins (including system packaged flash) were installed in per installation directories - different for mozilla provided binaries, custom firefox built from source, firefox esr etc. Now all the flexibility is gone.

Whether, this change intentional or not, it is a great PITA.

It broke openSUSE Tumbleweed, that ships FF 71 since yesterday. Today, I couldn't manage my vSphere servers anymore, and it took a while, before I twigged, what's going on (checked out the build, setup with quilt, grepped through 3.8 GB, finally located now passed away MOZ_PLUGIN_PATH).

Firefox is started from a script here, that exports MOZ_PLUGIN_PATH=/usr/lib64/browser-plugins, where distribution wide plugins are installed.

Thanks goes out to the Mozilla Foundation. You know, how to snub your users.

(In reply to atler from comment #6)

This seems to be intentional change of bug 1580282, which appears to break many distributions. In my distribution system provided plugins (including system packaged flash) were installed in per installation directories - different for mozilla provided binaries, custom firefox built from source, firefox esr etc. Now all the flexibility is gone.

Sorry for breaking your workflow. Can you help me understand what the point of this flexibility is? Flash is the only supported plugin, and we normally block pretty much all versions of flash other than the most recent few anyway. So I don't understand why you'd want/need different plugin versions for different builds run by the same user on the same machine.

Reverting priority not because I don't think this is important, but ironically, our triage processes mean bugs without a priority get looked at, and bugs with priorities do not, which is why this has sat here for 2 months unnoticed... if a bug is P1, it should have an assignee to work on it. Hopefully this way this'll show up in triage for the component owner in case this drops off my radar.

The simple answer is "because that's how our browser-plugins mechanism works", meaning assuring that every installed browser finds plugins in expected location. I have no trouble switching to one common directory as long as you extend support for where this common directory is located. We have strict rules of where binaries land -- only 32bit libs can go to /usr/lib, 64bit go to /usr/lib64. Also support for installing 32bit and 64bit browser at the same time is essential and we won't start renaming plugins to avoid conflicts because Mozilla supports single directory.

As mentioned earlier there might be legacy plugins other than flash which still rely on old plugins behavior, though from your statement about supporting flash exclusively, you don't consider it a valid point.

(In reply to atler from comment #9)

The simple answer is "because that's how our browser-plugins mechanism works", meaning assuring that every installed browser finds plugins in expected location. I have no trouble switching to one common directory as long as you extend support for where this common directory is located.

FWIW, I'm not 100% sure what you mean by this last part.

We have strict rules of where binaries land -- only 32bit libs can go to /usr/lib, 64bit go to /usr/lib64. Also support for installing 32bit and 64bit browser at the same time is essential and we won't start renaming plugins to avoid conflicts because Mozilla supports single directory.

Between https://searchfox.org/mozilla-central/rev/3fd53c47864fedb916f0ed8f002f15456324f729/xpcom/io/moz.build#147-148 and https://searchfox.org/mozilla-central/rev/3fd53c47864fedb916f0ed8f002f15456324f729/xpcom/io/nsAppFileLocationProvider.cpp#163-164,167-168 (first landed in bug 496708, a decade ago!), my understanding is we already support either /usr/lib/mozilla/plugins or /usr/lib64/mozilla/plugins depending on whether the browser itself is compiled as 64-bit, and 64-bit and 32-bit flash plugins are both available. Does that not help?

O(In reply to :Gijs (he/him) from comment #10)

(In reply to atler from comment #9)

The simple answer is "because that's how our browser-plugins mechanism works", meaning assuring that every installed browser finds plugins in expected location. I have no trouble switching to one common directory as long as you extend support for where this common directory is located.

FWIW, I'm not 100% sure what you mean by this last part.

I meant that until recently we have populated /usr/lib64/firefox/plugins with symlinks to browser-plugins for custom firefox build, /usr/lib64/mozilla-firefox-bin/plugins for official build /usr/lib64/firefoxt60-esr/plugins for ESR build etc etc. We're ok to switch all of them to populating /usr/lib64/mozilla/plugins.

We have strict rules of where binaries land -- only 32bit libs can go to /usr/lib, 64bit go to /usr/lib64. Also support for installing 32bit and 64bit browser at the same time is essential and we won't start renaming plugins to avoid conflicts because Mozilla supports single directory.

Between https://searchfox.org/mozilla-central/rev/3fd53c47864fedb916f0ed8f002f15456324f729/xpcom/io/moz.build#147-148 and https://searchfox.org/mozilla-central/rev/3fd53c47864fedb916f0ed8f002f15456324f729/xpcom/io/nsAppFileLocationProvider.cpp#163-164,167-168 (first landed in bug 496708, a decade ago!), my understanding is we already support either /usr/lib/mozilla/plugins or /usr/lib64/mozilla/plugins depending on whether the browser itself is compiled as 64-bit, and 64-bit and 32-bit flash plugins are both available. Does that not help?

Except that official 64bit build is not using /usr/lib64 and we do provide package for official build:

$ strings /usr/lib64/mozilla-firefox-bin/libxul.so|grep 'usr.lib.*mozilla.plugins'
/usr/lib/mozilla/plugins

And what about distributions that use /usr/lib32? (we're not one of those)

:handyman, any suggestions on how we should move forward here? Per the discussion here, esp. comment #11 (I haven't verified myself but it seems perfectly plausible), I see at least the following options (there's probably others...):

1. switch to /usr/lib64/ for all our 64-bit builds (I'm not familiar enough with linux to know how likely this is to break other distros, though it seems plausible enough that it will...)
2. check both /usr/lib/ and /usr/lib64/ on 64-bit builds (ditto)
3. try reinstating support for MOZ_PLUGIN_PATH (which may be a bit painful given all the refactoring that's happened since...)
4. do nothing given we're likely (barring unforeseen covid-related things, cf. https://bugzilla.mozilla.org/show_bug.cgi?id=1581664#c0 😱) to be removing flash support this year anyway.

The simple solution is to support both new and old directory location. This allows linux distributions plenty of time to migrate to the new /usr/$(libdir)/mozilla/plugins

(In reply to :Gijs (he/him) from comment #12)

:handyman, any suggestions on how we should move forward here? Per the discussion here, esp. comment #11 (I haven't verified myself but it seems perfectly plausible), I see at least the following options (there's probably others...):

1. switch to /usr/lib64/ for all our 64-bit builds (I'm not familiar enough with linux to know how likely this is to break other distros, though it seems plausible enough that it will...)
2. check both /usr/lib/ and /usr/lib64/ on 64-bit builds (ditto)
3. try reinstating support for MOZ_PLUGIN_PATH (which may be a bit painful given all the refactoring that's happened since...)
4. do nothing given we're likely (barring unforeseen covid-related things, cf. https://bugzilla.mozilla.org/show_bug.cgi?id=1581664#c0 😱) to be removing flash support this year anyway.

you are not understanding kde-plasma expects to install a plugin that works as well.

(In reply to Jory A. Pratt [:anarchy] from comment #13)

Created attachment 9135268 [details] [diff] [review]
1003_plugins-dir-fixup.patch

The simple solution is to support both new and old directory location. This allows linux distributions plenty of time to migrate to the new /usr/$(libdir)/mozilla/plugins

The "old" location in this patch is just what some places (unclear which?) used for MOZ_PLUGIN_PATH, and wouldn't help other users of that env var, right? I don't see any evidence we used to have support for /usr/lib/nsbrowser/, or, per comment #9 / comment #11, that it'd help the issues with 32 vs 64-bit plugins/binaries...

This appears to be multiple issues but they can all be dealt with by restoring MOZ_PLUGIN_PATH behavior. The old system ended up full of cruft over the years but I think I can work up something manageable and contained. If so, we can have MOZ_PLUGIN_PATH back.

Nixpkgs need MOZ_PLUGIN_PATH (https://github.com/NixOS/nixpkgs/issues/76943): after Firefox is built from source and installed (in /nix/store/…-firefox-unwrapped-{version}), its install directory remains read-only, and when end users request Firefox with plugins of their choice, they get a shell script (in /nix/store/…-firefox-{version}) that launches the binary with appropriate MOZ_PLUGIN_PATH (and MOZ_SYSTEM_DIR for native-messaging-hosts).

(In reply to :Gijs (he/him) from comment #15)

(In reply to Jory A. Pratt [:anarchy] from comment #13)

Created attachment 9135268 [details] [diff] [review]
1003_plugins-dir-fixup.patch

The simple solution is to support both new and old directory location. This allows linux distributions plenty of time to migrate to the new /usr/$(libdir)/mozilla/plugins

The "old" location in this patch is just what some places (unclear which?) used for MOZ_PLUGIN_PATH, and wouldn't help other users of that env var, right? I don't see any evidence we used to have support for /usr/lib/nsbrowser/, or, per comment #9 / comment #11, that it'd help the issues with 32 vs 64-bit plugins/binaries...

You need to relook at esr branch, it currently still works fine with /usr/lib/nsbrowser in 32bit variant.

MOZ_PLUGIN_PATH is a ':'-separated list of folders (';' on Windows) that we search for when launching Flash -- the only supported browser plugin.

and if our linux io tracing catches stats (which it might not, I forget).

I'm not clear on this. Is this about file access telemetry? I don't see anything special going on wrt that in other uses of the nsIFile methods but I would imagine these metrics could exists. Can you point me in a direction that will help me get an answer? I can commit afterwards.

(I am not concerned about MOZ_PLUGIN_PATH and tests -- they would be failing currently if they needed it. And the repo tree shows no instances of the env var.)

(In reply to David Parks (dparks) (he/him) [:handyman] from comment #20)

and if our linux io tracing catches stats (which it might not, I forget).

I'm not clear on this. Is this about file access telemetry? I don't see anything special going on wrt that in other uses of the nsIFile methods but I would imagine these metrics could exists. Can you point me in a direction that will help me get an answer? I can commit afterwards.

(I am not concerned about MOZ_PLUGIN_PATH and tests -- they would be failing currently if they needed it. And the repo tree shows no instances of the env var.)

This is the Poison IO interposer that's part of the gecko profiler. I just checked, those jobs don't set MOZ_PLUGIN_PATH, so you're good to land without doing anything else.

https://hg.mozilla.org/mozilla-central/rev/b328bafad4e7

Nothing needed from me, bug is resolved.