Packaging firefox extensions

[romildo]

I want to package the Arc Firefox Theme, which complements the Arc Theme for desktop environments based on GTK. It is a set of three extensions for Firefox (*.xpi files) that should be installed into the Firefox extensions directory (${firefox-unwrapped}/lib/firefox-xx.x.x/browser/extensions/ I think).

Since the store is read-only, that can not be done directly. Therefore a means of installing Firefox extensions should be created in NixOS.

Would it be feasible to have a directory /run/current-system/sw/share/firefox/extensions containing symbolic links to installed extensions (*.xpi files), and make ${firefox-unwrapped}/lib/firefox-xx.x.x/browser/extensions be a symbolic link to it?

[joachifm]

I once dabbled with a firefoxWithExtensions expression, but gave up for some reason, but I think that is a viable alternative.

[joachifm]

To elaborate, the idea is that you create a suitable directory hierarchy, copying in extension data + firefox as necessary. I also wanted to be able to put in prefs.js, too, for a fully customized deployment.

[romildo]

cc @edolstra I am not experienced enough to implement it. Probably Firefox maintainers will need to collaborate on it.

[edolstra]

Making ${firefox-unwrapped}/lib/firefox-xx.x.x/browser/extensions a symlink is not feasible because it wouldn't work if Firefox is installed via nix-env.

Maybe Firefox has an environment variable similar to MOZ_PLUGIN_PATH for extensions?

[joachifm]

Relevant docs
https://developer.mozilla.org/en-US/Firefox/Enterprise_deployment
https://developer.mozilla.org/en-US/Add-ons/Installing_extensions
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Customizing_Firefox#Including_extensions_with_your_distribution_of_Firefox

[joachifm]

A crude variant of this is at https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/networking/browsers/tor-browser-bundle/default.nix#L159

[oxij]

Since this is an item on both SLNOS TODO and my own TODO I have a couple of comments. First, you have to have `firefoxWithPackages` for it to be useful (e.g. for running both tor-browser and firefox). Second, `tor-browser-bundle` expression indeed has a lot of hints, but it cheats by just placing those xpis into the same output with the browser. Meanwhile `firefoxWithPackages` needs to be able to run the browser from one /nix/store place and to load xpis from another (unless you're ok with recompiling `firefox` every time). It will probably just work with some `buildEnv` hackery, but it might need some patching of `firefox` (to make it consult env or something) since tor-browser patches that part of firefox extensively ("bundle"). Anyway, SLNOS overlords welcome your efforts. It's also a high-priority TODO item on my own list, so I will do it eventually (but I don't have time for any serious nix work ATM), so feel free to ask for any help if you wish to implement it. I would start by packaging a single xpi and experimenting with firefox to make it load it from /nix/store (with prefs, by merging them into a single buildEnv, etc).

[joachifm]

It doesn't have to recompile anything when you change the xpis so I don't consider it cheating.

[joachifm]

That is, I can declare both the prefs and extensions via config.nix and change them at will with minimal rebuilding.

[joachifm]

(the current version doesn't put the xpis in the same output, but they are symlinked).

[oxij]

It doesn't have to recompile anything when you change the xpis so I don't consider it cheating.

It repackages binaries made to be placed anywhere ("bundle").

That is, I declare both the prefs and extensions via config.nix and change them at will with minimal rebuilding.

Can you show an example of that, please?

[joachifm]

It repackages binaries made to be placed anywhere ("bundle").

I don't consider repackaging the runtime to be recompiling firefox. I'll grant that re-packaging an existing firefox runtime is inefficient, compared to patching, but patching adds a lot of friction on my end and so is infeasible. Naive application of buildEnv does not work.

Can you show an example of that, please?

Sure (this is with unpublished changes ontop of master):

{
  allowUnfree = true;
  allowBroken = false;

  packageOverrides = super: let self = {
    firefoxExtensions.treestyletab = super.stdenvNoCC.mkDerivation rec {
      name = "treestyletab-${version}";
      version = "0.19.2017031101";
      src = super.fetchgit { # needs submodules for makexpi, todo: fetch
        url = "https://github.com/piroor/treestyletab";
        rev = "refs/tags/${version}";
        sha256 = "01wjb0r7dr14xg2g3g588fx436nxp6myyik2ymkag81gv1v0fia5";
      };
      nativeBuildInputs = with super; [ zip ];
      buildPhase = ''
        $shell makexpi/makexpi.sh -n treestyletab -o
      '';
      installPhase = ''
        install -m 444 -D treestyletab.xpi $out/[email protected]
      '';
    };

    tor-browser-bundle = super.tor-browser-bundle.override {
      audioSupport = true;
      mediaSupport = true;

      extraExtensions = with self.firefoxExtensions; [ treestyletab ];
      extraPrefs = ''
        lockPref("extensions.torbutton.security_slider", 1); // 4=compat (default), 2=mid, 1=high

        // Work-around flickering in treestyletab
        pref("browser.tabs.animate", false);

        // For extraExtensions
        pref("xpinstall.signatures.required", false);
      '';
    };
  }; in self;
}

Changing prefs or extensions gives a nix-rebuild time of

nix-build . -A tor-browser-bundle  0.55s user 0.05s system 15% cpu 3.961 total

most of which is spent in the post fixup phase. For my purposes this feature is working to the point that the exact mechanics of it are irrelevant, though they could be greatly improved, for sure.

[joachifm]

Note also that the old binary bundle runs entirely from the Nix store (as far as the "bundled" payload is concerned), it only copies the initial bookmarks file into the runtime profile directory on first run, My main motivation for the for-source version is not firefox-with-extensions but tor-browser-bundle-from-source.

[joachifm]

... but eventually I'd hope that it could be subsumed by a more general construct.

[leo60228]

@joachifm Would/could this be merged into master?

[joachifm]

@leo60228 the pasted example above works as-is now. Due to lack of interest I've had little motivation to pursue it further.

[stale]

Thank you for your contributions.

This has been automatically marked as stale because it has had no activity for 180 days.

If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.

Here are suggestions that might help resolve this more quickly:

1. Search for maintainers and people that previously touched the related code and @ mention them in a comment.
2. Ask on the NixOS Discourse.
3. Ask on the #nixos channel on irc.freenode.net.

[leo60228]

still important to me, home-manager's implementation could be in nixpkgs and seems pretty popular

[joelmccracken]

I would LOVE this feature. I actually spent a decent chunk of time trying to figure out how to install firefox extensions automatically a long time ago, and it was quite hard. But anyway I'd love to see this, maybe I could hack on it at some point.

[stale]

I marked this as stale due to inactivity. → More info

[leo60228]

This is definitely still an issue. I have a custom implementation of this but it's pretty tied to home-manager and isn't really in a state to PR it.

[stale]

I marked this as stale due to inactivity. → More info

[YoshiRulz]

I believe this was resolved by #91724.

see also #105783 re: packaging popular extensions in Nixpkgs

[samueldr]

Assumed fixed.