This breaks things like enterprise configuration and multi line tabs via https://github.com/Izheil/Quantum-Nox-Firefox-Dark-Full-Theme/releases
system wide stuff in snaps usually goes into $SNAP_DATA, which translates to /var/snap/<snapname>/current or $SNAP_COMMON (/var/snap/<snapname>/common).
have you tried if the FF snap perhaps could use the customization from there ?
/usr/lib/firefox has never been meant for customizations, the method advertised in that github repository looks fragile and hackish, and it means so-called customizations have to be re-applied every time firefox is updated. This definitely won’t work with firefox packaged as a snap, because snaps are immutable.
2 Likes
/usr/lib/firefox is the supported folder for things like https://support.mozilla.org/en-US/kb/customizing-firefox-using-autoconfig (link from https://support.mozilla.org/en-US/questions/1338468)
It doesn’t need to be re-applied on apt based Firefox updates.
/usr/lib is not a supported place for modifications, overrides or configuration data in any distro, the dirs underneath it are typically exclusively for distro package data and on many enterprise systems /usr is even mounted readonly (and only made RW temporary for package updates) …
https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s06.html
local admin overrides normally go to /etc/ in linux … (in case of the firefox deb it used to go into the shipped /etc/firefox/pref/ dir which is explicitly there for overrides) …
just because the asking user in your above link used that dir for hacks it does not make it any more valid for general use …
1 Like
https://support.mozilla.org/en-US/kb/customizing-firefox-using-policiesjson says to put it in the “Firefox install directory” not /etc.
It’s not just some random forum post.
Can you install the snap’d firefox alongside the .tar based one to ease testing ?
you likely can (i never tried) … not sure how FF will behave then though, it is a bit weird in its way of trying to re-use running instances so things might mix and mesh at runtime (and break) … you’d have to try …
--no-remote will stop that 
That article points to policy-templates/README.md at master · mozilla/policy-templates · GitHub, which says:
On Linux, the file goes into
firefox/distribution, wherefirefoxis the installation directory for firefox, which varies by distribution or you can specify system-wide policy by placing the file in/etc/firefox/policies.
The firefox snap will respect and enforce policies found in /etc/firefox/policies.
“the installation directory for firefox” would work if you had installed it locally in e.g. /opt, or directly extracted an upstream tarball somewhere under your home directory. As pointed out by @ogra, it’s really not advisable to modify files under /usr.
That and the fact that the firefox snap will store its profiles under ~/snap/firefox/common, as opposed to ~/.mozilla/firefox for an upstream tarball, means that it should mostly work. This is not really tested though.
well, i think it would make sense to allow global customization, it should be as simple as adding a layout:
layout:
[...]
/etc/firefox/prefs:
bind: $SNAP_COMMON/prefs
so an admin can put global modification and overrides there (assuming FF will look in /etc/firefox/prefs as the deb build did)
“have you tried if the FF snap perhaps could use the customization from there ?”
It doesn’t seem like there is a suitable folder, I think @ogra would need to get the snap updated and then it could be tested ?
Unless there somewhere to make the /var/snap/… not read only ?
Good news, can have both snap and not-snap versions side by side, just faff.
i do not maintain the firefox snap, that is done by mozilla (with some help from @oSoMoN). i was just making a packaging suggestion …
this is RW by default and the place where snaps can put variable and global data as i explained above in my first post …
I’m confused. How do the places in /var/snap/… map to either /etc/firefox or /usr/lib/firefox ?
i was only reacting to your:
… it is not readonly …
When a snap package is launched snap-confine will be launched by snapd to create a “mount namespace” for the snap that allows for arbitrary mount points to be created by snap-update-ns. This is how the snap feature called “layouts” operates. The snap package can be configured at build time to request that a path e.g. in $SNAP_COMMON (i.e. /var/snap/$SNAP/common) be mounted in any other arbitrary location such as /etc/firefox. This is how a path in /var/snap can affect /etc/firefox.
Thanks for the detailed explanation @lucyllewy.
In the case of firefox though, the snap uses the system-files interface to expose /etc/firefox/policies from the host system, rather than mounting a different path there. This is for compatibility with traditional (e.g. deb) packages.
1 Like
aha, that’s a good point. I didn’t think about the system-files interface when I was writing that… 
So are we saying it should work with policy files in /etc/firefox/policies already ?