1332404 - System wide plugin directory cannot be customized prefix provided in .mozconfig

Status: UNCONFIRMED

Description

[michal]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0
Build ID: 20170112000455

Steps to reproduce:

I am building Firefox with the custom prefix, by providing the following option in .mozconfig:

ac_add_options --prefix=/app

or:

ac_add_options --prefix=/opt


Actual results:

Firefox is looking for the system wide plugins in /usr/lib64/mozilla/plugins, despite the fact that I'm not using /usr as the prefix.

That's because the paths are hardcoded and determined by architecture and/or operating system:
https://github.com/mozilla/gecko-dev/blob/master/xpcom/io/nsAppFileLocationProvider.cpp#L190-L195


Expected results:

In my opinion, Firefox should use prefix from build system to determine this directory. So, after setting up the prefix in .mozconfig, it should look like:

$(prefix)/lib/mozilla/plugins
$(prefix)/lib64/mozilla/plugins

depending on the architecture for which it's built. In example, if I use /opt as a prefix, I expect to have:

/opt/lib/mozilla/plugins
/opt/lib64/mozilla/plugins

The one of the major use cases of the custom prefix is distributing Firefox in flatpak <http://flatpak.org/>, which is using /app prefix for applications (and /usr is read-only).

Comment 1

[michal]

I can work on this and provide a patch if the idea makes sense for you.

Also, there is a ticket regarding putting Firefox in flatpak:
https://bugzilla.mozilla.org/show_bug.cgi?id=1278719

Comment 2

[Ted Mielczarek [:ted.mielczarek]]

We've already removed support for all NPAPI plugins except Flash (bug 1269807), so this doesn't seem worthwhile.

Comment 3

[michal]

Well, if Flash is an exception, IMO this bug is still valid, unless you have plans to change the location for flasphlugin or any other plan which would change the code I linked. I think that Flatpak users would like to use Flash and it would need to be distributed somehow for them.

Using $HOME/.mozilla directory is not a very nice solution, because homedir isn't accessible for flatpak on building or installation phases. And it may be similar in case of another app sandbox solutions as well, I guess.

What do you think?

Comment 4

[Benjamin Smedberg]

I'd take a patch for this as long as it suits these invariants:

* In the Mozilla distributed builds, it always looks in /usr/lib/mozilla/plugins regardless of architecture (32 or 64). This is required because of the packaging differences between debian-like (lib and lib32) and Redhat-like (lib and lib64) distros.
* It doesn't screw up distributions that already customize this.

But realistically I recommend you just keep a custom patch for this particular variation.

Comment 5

[Mike Kaply [:mkaply]]

We're looking at being responsible for the Flatpak builds, so we would need some version of this change in Firefox.

We're going to need a custom Flatpak build anyway (to turn off the updater), so if this is a Flatpak only change, I could see adding a --enable-flatpak or something to that effect that turns this on in that one case.

Based on the original report, though, I'm confused why we're not honoring prefix in that case. Should we be?

Comment 6

[Mike Kaply [:mkaply]]

Is this still an issue for Flatpaks?