1786742 - Firefox Snap does not read same configuration locations as binary version

Status: RESOLVED WONTFIX

(Firefox Build System :: Third Party Packaging, defect)

Description

[tc]

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

Steps to reproduce:

Use /usr/lib/firefox to customize Firefox.

Putting files in /etc/firefox/profile doesn't appear to work as a work around.

Snapcraft thread : https://forum.snapcraft.io/t/firefox-snap-no-longer-reads-usr-lib-firefox-for-customization/29713/24

FireFox security asked about related issues in https://github.com/xiaoxiaoflood/firefox-scripts/issues/64 9 months ago.

Example customization that does not work on Snap firefox : https://github.com/xiaoxiaoflood/firefox-scripts#instructions

These are required, for instance, for https://github.com/onemen/TabMixPlus/#readme which re-enables multirow tabs after they were removed from core.

Actual results:

Scripts do not appear to load

Expected results:

Scripts load

Comment 1

[Olivier Tilloy]

Is dropping customizations (config.js and defaults/pref/config-prefs.js) in /usr/lib/firefox/ (or at the root of the unpacked tarball distributed by Mozilla) something that is supported by Mozilla?

This won't work for the snap, because the snap's filesystem is read-only.

Comment 2

[tc]

I believe so, http://kb.mozillazine.org/Locking_preferences says to use http://kb.mozillazine.org/Installation_directory which says it's /usr/lib/firefox for instance.

Comment 4

[:gerard-majax]

(In reply to tc from comment #2)

I believe so, http://kb.mozillazine.org/Locking_preferences says to use http://kb.mozillazine.org/Installation_directory which says it's /usr/lib/firefox for instance.

That's /usr/lib/firefox on packaged builds, but I am not sure this holds for Snaps.

Comment 5

[Tom Chiverton]

Yes, that's the point of this bug-there is no where to perform the same configuration in Snap Firefox as there is in the traditional binaries.

Comment 6

[:gerard-majax]

There is /etc/firefox/policies which is exposed by the Snap, what would be wrong about more of them in /etc/firefox ?

Comment 7

[:gerard-majax]

Couldn't we use /etc/firefox ?

Comment 8

[tc]

I tried that, see thread linked from top post.

Comment 9

[:gerard-majax]

(In reply to tc from comment #8)

I tried that, see thread linked from top post.

There are many things in that post, and the specific message linked does not only includes /etc/firefox/policies content, but other files. You mention « script does not load » but there are several JS files, so which one is not? If it's those under /etc/firefox only, it's not surprising since this is not (yet?) allowed by the Snap configuration.

Comment 10

[tc]

As far as I can tell, nothing at all happens.

But I am not an expert in FireFox settings, or these sorts extensions themselves. But I want to help :)

If there is an way to drop a dummy .js file like those in https://github.com/xiaoxiaoflood/firefox-scripts#instructions into somewhere the Snap FireFox should read from, and some way to check they run, happy to do that, but IDK what I'm doing really.

Comment 11

[Olivier Tilloy]

Locking preferences can be achieved using policies under /etc/firefox/policies, and I believe this is the preferred approach in an enterprise setting (correct me if I'm wrong).

Comment 12

[Olivier Tilloy]

(In reply to Alexandre LISSY :gerard-majax from comment #7)

Couldn't we use /etc/firefox ?

We could certainly do that, but again I want to make sure this use case of dropping random files that modify the behaviour and appearance of the browser is actually supported by Mozilla, before we go ahead.

Also the installation directory in a traditional package would be /usr/lib/firefox, not /etc/firefox. Is firefox going to look up in both for custom js files to include?

Comment 13

[Mike Kaply [:mkaply]]

Enabling Autoconfig would not be enough. These tools use all kinds of other (unsupported) methods to load files into the Firefox chrome scope.

If you want to do these kinds of things, don't use the Snap.

I think we should close this as WONTFIX.

Comment 14

[Simmo Saan]

Enabling AutoConfig might not be enough for the aforementioned firefox-scripts stuff, but it would be precisely sufficient for https://bugzilla.mozilla.org/show_bug.cgi?id=1785278 which was marked as a duplicate of this more general issue.
As far as I can tell, AutoConfig is still a supported method, unless this official documentations is then wrong: https://support.mozilla.org/en-US/kb/customizing-firefox-using-autoconfig.

So does this being WONTFIX mean that even just AutoConfig for snap should not be supported? After all, the first sentence of the AutoConfig documentation describes it as a method for things that are not possible through policies, which are supported under snap.

Comment 15

[Mike Kaply [:mkaply]]

Agreed, and I'll address in the other bug.

Comment 16

[:gerard-majax]

While not all cases listed can be enabled, AutoConfig is landing in bug 1785278

Comment 17

[Tom Chiverton]

I got a needinfo email. Not sure why.

Comment 18

[:gerard-majax]

(In reply to Tom Chiverton from comment #17)

I got a needinfo email. Not sure why.

I sent a needinfo to [e-mail] since this was the person reporting the issue to keep them informed of the progress?

Comment 19

[Tom Chiverton]

Strange use of "needinfo" but if that's the way it works fine. Sounds like stuff is happening.

Comment 20

[:gerard-majax]

Sorry for thinking you might be interested in knowing we could improve the situation you reported ?

Comment 21

[Tom Chiverton]

Oh, I am, as I said :)

"needsinfo", to someone who doesn't use Mozilla a lot, meant something else to me and I spent ages reading the email looking for the question.

No big deal.

Comment 22

[:gerard-majax]

No, I'm using needinfo especially with contributors to make sure they have a way not to forget about the information (you have the red dot on bugzilla and periodic reminders if you dont reply), not just to ask questions :)