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.
1 Like
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.
1 Like
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)
1 Like
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)
I’ve now changed the automatic generation of Firefox addon packages somewhat and will eventually remove the overlay provided in Robert Helgesson / nixpkgs-firefox-addons · GitLab.
Instead, the addon packages are available through my NUR repo. So if you have NUR installed you can access the Firefox addons under nur.repos.rycee.firefox-addons. E.g.
$ nix-env -f '<nixpkgs>' -qaP -A nur.repos.rycee.firefox-addons
nur.repos.rycee.firefox-addons.cookie-autodelete cookie-autodelete-3.0.1
nur.repos.rycee.firefox-addons.decentraleyes decentraleyes-2.0.10
nur.repos.rycee.firefox-addons.greasemonkey greasemonkey-4.7
nur.repos.rycee.firefox-addons.https-everywhere https-everywhere-2019.1.31
nur.repos.rycee.firefox-addons.link-cleaner link-cleaner-1.5
nur.repos.rycee.firefox-addons.octotree octotree-2.5.6
nur.repos.rycee.firefox-addons.privacy-badger privacy-badger-2019.2.19
nur.repos.rycee.firefox-addons.reddit-enhancement-suite reddit-enhancement-suite-5.14.5
nur.repos.rycee.firefox-addons.save-page-we save-page-we-13.3
nur.repos.rycee.firefox-addons.stylus stylus-1.5.2
nur.repos.rycee.firefox-addons.swedish-dictionary swedish-dictionary-1.19
nur.repos.rycee.firefox-addons.ublock-origin ublock-origin-1.18.6
The package set is still automatically updated once per day.
Basically I like the idea of NUR and figured it was natural to include these packages there. I would have done it earlier but couldn’t find the time to set things up properly.
For the user the benefit is mainly that you’ll have access to everything in NUR, not just these Firefox addons and you don’t have to do any specific configuration just for the Firefox addons package set.
For me the benefit is that my repository setup becomes a bit more sensible. I have one repository for the update tool and a separate repository for the Nix expressions. So now the generated Nix files are under version control, before they were simply packaged up in a tarball and hosted on GitLab.
1 Like
I have a similar problem.
I have (EDIT: not!) gone through this entire thread yet but the gist I’m getting is that the location for extensions isn’t /run/currenr-system/…/extensions but the extensions folder in the actual Firefox store path.
@rycee sorry for my trivial questions:
- Is it possible to set extension configurations? For example, if I have FoxyProxy that is used to set a proxy, can I configure the configs of the extension in a declarative manner?
- Less related: if I have a HTML file with hundreds of bookmarks, is it possible to import this file in Firefox in a declarative manner?