Any chance to have a Firefox module in NixOS?

1

Firefox has a wrapper with rich features. I can add many configs with a overlay. But it’s not very easy to discover those wrapper options without reading the code and it’s not well-documented. A nixos module for firefox is a natural idea to provide a better UX.

There is already a module for chromium and there is a PR for firefox module. Unfortunately it only got a comment that home-manager should be used instead. Home-manager is good and it has a good firefox module. However I’m a NixOS user instead of a HmOS user. There is a function in home-manager is not s solid reason to block a function in NixOS. As the only user on my NixOS, I don’t want to intruduce a third-party tool to manager my system which is not even a NixOS module. (I’d be happy to use home-manager if it’s integrated into NixOS.)

Maybe a Firefox module in NixOS has less features than the one in home-manager, it can serve as a good abstract and UI of the wrapper.

1 Like
2

You can use e.g.:

nixpkgs.config.firefox = {
  enableGnomeExtensions = true;
};

Though not every setting of the wrapper is exposed through its cfg parameter.

EDIT: note that this is universal for anything using the wrapper, so you can also use nixpkgs.config.thunderbird the same way.

3

I think it is a bit problematic because it makes Firefox configuration a thing system-wide and controlled by the superuser.

About NixOS and HM integration, I have mixed feelings. On the oldschool days without flakes and overlays, NixOS and Nixpkgs were merged in a monorepo fashion in order to help development.

However, I don’t believe it would be good to do the same with HM, precisely because we are now with flakes and overlays.

On the other hand, if Chromium has its own module, I have no argument against Firefox.

1 Like
4

Yes, only a few configs are exported and it’s still difficult to discover it. E.g., the enableGnomeExtensions is exported while extraNativeMessagingHosts is not.

In the other hand, it also has benefits, e.g. the system admin can apply some system-wide policies. Since the nixpkgs config and overlays are also system-wide it seems there is no difference on this aspect.

1 Like
5

The config is easily overridden per-user. But in the config you can do also overrides and overlays, so it’s not really different in that respect. I mean, it’s orthogonal whether you choose to do it in your NixOS config.

6

The module in my PR uses system policies, whereas the Home Manager equivalent modifies the settings file for a specific user.

A policy locks down settings in the UI, which could be useful if an organisation needs to restrict certain features. IMO this is also more user friendly because users can see what has been configured through NixOS, whereas with Home Manager you are able to change the settings freely only to have them reverted after the next rebuild.

The existing Chromium module uses this same technique, so I see no reason not to have a corresponding module for Firefox.

I think it is a bit problematic because it makes Firefox configuration a thing system-wide and controlled by the superuser.

Firefox does display a message when system policies are in use, so users are aware that this is the case.

7

I’m getting a message even without it, due to disabled updates:

Your browser is being managed by your organization.

8

I’m getting a message even without it

Does /etc/firefox/policies/policies.json exist for you? If so what does it contain?

The module could be generating a blank file, which would trigger the message even if there are no policies set.

9

The file doesn’t exist.

10

Looks like this is done by the wrapper:

So that message appearing is already a thing without this module.

As the wrapper already supports policies, should the module just pass its arguments through to there? Currently it installs policies separately to /etc.

11

I suspect that’s rather different. Individual users can’t avoid policies in /etc, I expect, but they can easily install differently wrapped firefox in various ways.

12

Makes sense.

Aside from running a container or VM I can’t think of any other ways to avoid the policies in /etc.

So the package policies should only be used for packaging details such as disabling updates, and perhaps installing extensions.

13

The current way is not better where some modules are vendored from NixOS into hm.
Actually I am thinking since a bit about expanding users.users to fit common HM usecases that most NixOS users no longer would need to use it.

14

Please ping me with your thoughts on that if you don’t mind. It is something I have spent some time thinking about in the past so I would love to hear what your thoughts are.

15

Another thing about home-manager is about a concept I have seen in OpenIndiana: the packages grounding the system don’t need to be the same the user will find.

In this sense, home-manager is still valuable because a user can confugure its own $HOME regardless the underlying system. Indeed, HM can be run in other distros.

16

Not sure how policy is different from preference in extraPrefs. But I thought we can have both.

17

I didn’t really think about specifics yet but I dropped you a message on matrix.

I don’t want to touch that. Supporting other distros is opening a pandoras box because they do things little bit different and usually are a bit outdated. I plan more for removing the use case for home-manager from a single user nixos installation which uses the home-manager nixos module.

18

A post was split to a new topic: Question about Firefox module extension handling