hear be a shell script “to handle Firefox 60+ extensions
Manage installation, upgrade and removal of system wide and user extensions”
perhaps? #… at least for me this reads easier than .hs =P
this could be utilised some how to output ( firefox + extensions ).
plain text of the link
#github.com/
PLAIN-TEXT-LINK: NicolasBernaerts/ubuntu-scripts/blob/master/mozilla/firefox-extension-manager
because apparently discourse edits links on my behalf 
FTR this is a/the permanent link to the latest most updated version for humans 
The problem with that is that all methods of managing extensions that Firefox makes available which do not touch the profile directory are imperative instead of declarative, allowing only instructions to install or uninstall extensions from the profile directory.
I don’t believe there can be any NixOS solution less complicated than running Firefox in a way that shadows the extension directory (user namespace + bindmount?) - so we will probably have to use home-manager and just accept that one profile must correspond to one set of extensions.
I don’t believe there can be any NixOS solution less complicated than running Firefox over a FUSE layer that shadows the extension directory - so we will probably have to use home-manager and just accept that one profile must correspond to one set of extensions.
There might be some solution along the lines of running Firefox during nix-build to initialise the extension directory, then overwrite the profile’s extensions directory on start. (I do that with whole profile, which is a bit easier, but maybe partial profile overwrite also works fine with some care).
What about this mechanism: Deploying Firefox with extensions | Firefox for Enterprise Help
Maybe combined with Customizing Firefox Using AutoConfig | Firefox for Enterprise Help
Both of those will install extensions to a users directory, leaving them there when started with a Firefox version without extension or when they are removed from the configuration.
Right, didn’t consider that. Apparently it is possible to install and remove addons using the windows registry. Maybe that code could be re-used for our usecase with a small patch.
GitHub - mozilla/policy-templates: Policy Templates for Firefox can be used to force extensions to be installed in a declarative way.
But it also requires a policies.json file in the “installation directory”, so we should solve that problem first.
In my private nix config, I solve this by using bind mounts + user namespaces in a wrapper, which sets things up, so firefox sees the distribution directory under the correct path. But that’s probably too complex for an “official” solution.
What is the “installation directory”?
That’s not well documented as far as I can see (at least I had trouble finding documentation), but it appears to be the directory where the shared libraries can be found.
$(nix eval --raw nixpkgs.firefox-unwrapped)/lib/firefox/ in our case, to be precise.
Edit: GitHub - mozilla/policy-templates: Policy Templates for Firefox says:
On Linux, the file goes into firefox/distribution, where firefox is the installation directory for firefox, which varies by distribution.
That apparently means /lib/firefox/distribution for us.
That shouldn’t be too hard to do right? Just make a wrapper that copies firefox $out, adds the profile.json and patch all self-references of firefox if necessary.
Yes, that’s what the tor-browser-bundle derivation does I think. But then if you have multiple variants of the wrapper, it will consume a lot of disk space. Maybe that is acceptable though?
By the way, I did find a reference for the “install directory” stuff here: Firefox/EnterprisePolicies/Testing - MozillaWiki
You can run Services.dirsvc.get(“XREAppDist”, Ci.nsIFile).path in a browser console to get the right directory.
firefox-unwrapped only is 148M, I think that is okay. Most people will only have one version anyways.
If the ff code is clean and the location of profile.json is defined in a central place, we could also patch that to take the location from an environment variable or a flag. Then use a normal wrapper.
firefox-unwrappedonly is 148M, I think that is okay.
And how much do we need to copy anyway? Maybe most of the things can be just symlinked?
(although taking from environment would also be nice)
A naive search through firefox-unwrapped shows no back references, except a wrapper script that doesn’t even seem to do anything:
$ rg --hidden --no-ignore --text 'igr92m1c10cahcngda5n2v88g7z46vkr'
bin/firefox
6:exec -a "/nix/store/igr92m1c10cahcngda5n2v88g7z46vkr-firefox-unwrapped-65.0.2/bin/.firefox-wrapped" "/nix/store/igr92m1c10cahcngda5n2v88g7z46vkr-firefox-unwrapped-65.0.2/bin/.firefox-wrapped" "${extraFlagsArray[@]}" "$@"
So probably pretty much everything could be symlinked. You could make a separate derivation juts for profile.json and then use symlinkJoin or something.
The wrapper script is /nix/store/igr92m1c10cahcngda5n2v88g7z46vkr-firefox-unwrapped-65.0.2/bin/firefox and it does some work. But I agree, that that’s not a fundamental problem.
What can be symlinked depends on what part of firefox actually resolves the paths.
If its libxul (~100M) for example, then we can’t symlink that :-/
Why not?
(post needs to be 20 chars)
Because it will try to resolve the symlink and expect the configuration files to be found in the correct paths relative to its “true” location.
But I just tried and found that its the actual “firefox” executable at firefox-unwrapped/lib/firefox/firefox, which does the resolving. It would have to be copied, but the rest can be symlinked, and its only a few k.
Edit: Ok, actually that’s to be expected, after all the other things there are shared libraries. It would be extremely odd for paths to be resolved relative to one of them.
Ok, I opened WIP: firefox/wrapper.nix: make firefox wrapper configurable by the user by xaverdh · Pull Request #57554 · NixOS/nixpkgs · GitHub just to get things started.
Update: so you can test this by checking out my pull request and using
firefox.override { extraPolicies.Extensions.Install = [ “https://addons.mozilla.org/firefox/downloads/file/1671300/decentraleyes-latest-an+fx.xpi” ]; }
(replacing the url by the extension of your choice)