Why is Nix's Firefox not shipping Pipewire support by default?

According to the NixOS wiki it seems that Firefox does not ship with Pipewire by default.
While the usage of Pipewire (and desktop portals as well) is required to enable screensharing (along xdg-desktop-portal) on Wayland compositors, alas it is not the default as it is for Chromium, which means Firefox users cannot share their screens.

I understand that Firefox support for pipewire is likely experimental and it was kept disabled by default (just like many things like hardare acceleration are/have been for a long time), but considering that ttwo major DEs like GNOME and KDE have made a commitment to be Wayland-first and disabling X11 sessions altogether, asking users to put extra config to enable screen sharing does not feel user-friendly or forward-looking.
Besides, those changes also come at a cost of making a new derivation for firefox, triggering a recompilation that in my opinion should be avoided.

So I would like to ask the NixOS community, in particular Firefox maintainers:

  • Are there are technical limitations that prevent pipewire from becoming included by default
  • If it would at least be possible to include a variant of Firefox for Wayland, at least on some community cache like Cachix… or if somebody already did, please let me know.
  • More generally, from the perspective of NixOS development, what is the stance about the migration towards Wayland? I mean, specifically about automatically enabling e.g. portal support, the right environment variables etc.

As for why I am bringing this up, in my job I often have meetings via web zoom and the like and often have to use screen sharing. I could use chrome, but I feel more comfortable on Firefox. Pipewire support used to be more buggy in the past but it feels stable enough now, or at least this is my anecdotal experience. But recompiling Firefox every time a new subrelease comes around is quite annoying.

It supports pipewire by default, the author of the wiki entry doesn’t know what they’re doing: https://github.com/NixOS/nixpkgs/blob/d542db745310b6929708d9abea513f3ff19b1341/pkgs/build-support/build-mozilla-mach/default.nix#L138

To my knowledge this has never been false, either; Screensharing with Firefox on wayland has worked for me since I started using it in early 2023.

They might have enabled privacySupport and not realized this has knock-on effects?

2 Likes

Mhh I shouln’t have trusted the wiki :confused:

Indeed now it works.
But I wonder, why does explicitly enabling pipewire via firefox-unwrapped cause the package to be recompiled every time? If pipewire really is needed, explicitly setting it to true shouldn’t change the underlying derivation, right? Unless firefox-unwrapped was built by another derivation with a different set of options.
So… what is the deal with firefox-unwrapped?

Yep. I don’t know what else you have in your configuration, so I assume something else is causing that, maybe some library overrides or perhaps you’re using a -small channel or something.

That or you’re misattributing the build of the wrapper to a rebuild of Firefox?

In either case, I’d suggest using the programs.firefox option and not mucking with overrides, wrappers or anything of the sort.

1 Like

I had it as an override, but I installed firefox via the HM module.
(there is no good reason except that at first I didn’t adopt the firefox module but pipewire didn’t work for some reason)

Disabling the override and sticking to the module config did the trick.
I’ll mark this as solved.

@TLATER Nevermind, I’ll open this again

today I have upgraded my nix flake (I am still on 25.05), and guess what? I was still rebuilding firefox! (specifically, firefox-unwrapped-145.0.2)

My config for firefox is literally this piece from HM:


{ config, pkgs, ... }:

{
  programs.firefox = {
    enable = true;
    #package = pkgs.firefox;
    # profile settings ...
    nativeMessagingHosts = with pkgs; [
      # kdePackages.plasma-browser-integration (no longer necessary
      jabref
    ];
  };
}

Now, I was wondering if firefox-unwrapped was not on the hydra cache but it seems it is.

The only thing that comes to mind that there could be interfering overlays, but I have checked and the only overlays I have are 100% completely unrelated as they are standalone applications like Slack and not libraries. The only possibility is an overlay that I called openconnect-master, but a) it has a separate name from openconnect, b) I am fairly sure it is in no way a (direct or indirect) dependency of firefox.
The only way to avoid triggering a recompilation is by using firefox-bin.

But, running nix-shell on a separate shell after the switch quickly downloads me /nix/store/8i7x12lms8903wa8lw3kzfwakhxhpmcb-firefox-145.0.2. I conclude that HM must be doing something funky…

Hard to pinpoint if you don’t share your full configuration. It’s definitely not either of the module systems, I’ve been using both to configure firefox for nearly a decade without a hitch.

More likely your inputs point at a channel that doesn’t wait for the firefox build or something along those lines. That, or your overlays do in fact end up in the firefox dependency chain; if you use overlays only for leaf packages you shouldn’t be using overlays to begin with, tbh, just use the package attributes directly without abusing pkgs as a global variable to dump cruft into for no reason.

It’s hard to share my config because it’s scattered on many files and it’s a bit of a WIP and I don’t feel like sharing some sensitive stuff.

But it is something like this:

flake.nix

{
  description = "erolm_a's new nix configuration";

  inputs = {
    nixpkgs.url = "github:NixOS/nixpkgs/release-25.05";
    nixos-hardware.url = "github:NixOS/nixos-hardware/master";
    home-manager = {
      url = "github:nix-community/home-manager/release-25.05";
      inputs.nixpkgs.follows = "nixpkgs";
    };
  };

  outputs = inputs@{ self, nixpkgs, home-manager, nixos-hardware, ... }:
    let
      system = "x86_64-linux";
      pkgs = import nixpkgs {
        inherit system;
        config.allowUnfree = true;
      };
      makeNixosConfig = host: extraModules:
        lib.nixosSystem {
          inherit system;
          # Horrible way to do this, I know
          # specialArgs = { inherit pkgs-unstable pkgs-unstable-unwrapped; };

          modules = extraModules ++ [
            ./hosts/${host}/nixos.nix
            ./cachix.nix # fixme
            ./steam.nix
            inputs.home-manager.nixosModules.home-manager
            {
              home-manager = {
                useGlobalPkgs = true;
                useUserPackages = true;
                backupFileExtension = "backup";
                users.erolm_a = import ./hosts/${host}/home-settings.nix;
              };
            }
          ];
        };



      lib = nixpkgs.lib;
    in {
      nixosConfigurations = {
        dell-xps-nixos = makeNixosConfig "dell-xps"
          [ nixos-hardware.nixosModules.dell-xps-15-7590-nvidia ];
      };

      # unrelated stuff ...
    };
}

Then under home.nix:


{ config, pkgs, nix-alien, lib, ... }:

{

  imports = [ ./firefox ./dev ];

  options.custom = {
    nixos = lib.mkOption { type = lib.types.bool; };
    #steam = lib.mkOption { type = lib.types.bool; };
    dev = lib.mkOption { type = lib.types.bool; };
    personal = lib.mkOption { type = lib.types.bool; };
    wayland = lib.mkOption { type = lib.types.bool; };
    username = lib.mkOption { type = lib.types.str; };
    configPath = lib.mkOption { type = lib.types.path; };
  };

  config = {
    nix = {
      #registry.nixpkgs.flake = inputs.nixpkgs;

      gc = { automatic = true; };
    };

    home.username = config.custom.username;
    home.stateVersion = "24.11";

    home.homeDirectory = "/home/${config.custom.username}";

    home.packages = with pkgs;
      [

        # lots of packages here
        # But not firefox

      ] ++ (if config.custom.personal then [
  # other packages only to install on this host
      ] else
        [ ]);

    # config of unrelated stuff

    programs.home-manager.enable = true;

    dconf.settings."org/gtk/settings/file-chooser" = {
      sort-directories-first = true;
    };

    # GTK4 Setup
    dconf.settings."org/gnome/desktop/interface" = {
      gtk-theme = pkgs.lib.mkForce "Breeze";
      color-scheme = "prefer-dark";
    };

    xdg = {
      portal = {
        config = { common = { default = [ "kde" ]; }; };
        enable = config.custom.wayland;
        extraPortals = with pkgs; [
          xdg-desktop-portal-wlr
          xdg-desktop-portal-gtk
          kdePackages.xdg-desktop-portal-kde
        ];
      };
    };

    programs.sioyek = {
      enable = true;
      config = {
        shared_database_path = "/home/erolm_a/phd/.sioyek_shared.db";
        super_fast_search = "1";
      };
    };

    programs.mpv = {
      enable = config.custom.personal;
      config = {
        gpu-api = "vulkan";
        hwdec = "nvdec";
        hwdec-codecs = "all";
      };
    };

    # Services
    services.mpris-proxy.enable = true;

  };

}

Lastly, firefox/default.nix is what I shared above.

There is absolutely no nixpkgs-unstable.

In hosts/dell-xps/nixos.nix, I have commented all the overlays for extra safety. It still tries to build firefox.

I have also tried removing the other host entry from flake.nix, but to no avail.

As for the lock file itself:

{
  "nodes": {
    "home-manager": {
      "inputs": {
        "nixpkgs": [
          "nixpkgs"
        ]
      },
      "locked": {
        "lastModified": 1763992789,
        "narHash": "sha256-WHkdBlw6oyxXIra/vQPYLtqY+3G8dUVZM8bEXk0t8x4=",
        "owner": "nix-community",
        "repo": "home-manager",
        "rev": "44831a7eaba4360fb81f2acc5ea6de5fde90aaa3",
        "type": "github"
      },
      "original": {
        "owner": "nix-community",
        "ref": "release-25.05",
        "repo": "home-manager",
        "type": "github"
      }
    },
    "nixos-hardware": {
      "locked": {
        "lastModified": 1764440730,
        "narHash": "sha256-ZlJTNLUKQRANlLDomuRWLBCH5792x+6XUJ4YdFRjtO4=",
        "owner": "NixOS",
        "repo": "nixos-hardware",
        "rev": "9154f4569b6cdfd3c595851a6ba51bfaa472d9f3",
        "type": "github"
      },
      "original": {
        "owner": "NixOS",
        "ref": "master",
        "repo": "nixos-hardware",
        "type": "github"
      }
    },
    "nixpkgs": {
      "locked": {
        "lastModified": 1764628670,
        "narHash": "sha256-fJqJkB/qHwFYF4ot/NL2O5ZiM+TNPZXF+N0/TURElO8=",
        "owner": "NixOS",
        "repo": "nixpkgs",
        "rev": "62d844fe2a0efe1cd01a6294c77050875d2e5ba0",
        "type": "github"
      },
      "original": {
        "owner": "NixOS",
        "ref": "release-25.05",
        "repo": "nixpkgs",
        "type": "github"
      }
    },
    "root": {
      "inputs": {
        "home-manager": "home-manager",
        "nixos-hardware": "nixos-hardware",
        "nixpkgs": "nixpkgs"
      }
    }
  },
  "root": "root",
  "version": 7
}

Your nixpkgs flake input is pointing at the wrong branch, causing your rebuilds. For nixpkgs: use nixos-* branches not release-*, and you should switch to 25.11 as 25.05 is deprecated.

1 Like

I am not sure what the difference between these branches is.

But anyway, that is not the reason. I think I figured it out

I have omitted something very important: in hardware-configuration I have globally set up CUDA support via nixpkgs.config.cudaSupport = true

Apparently, one of firefox’s dependencies, onnxruntime, has a facultative dependency on CUDA, hence the derivation is different and it gets rebuilt.
Remove global cuda support and voit lĂ , no more recompilation.

I think I have learnt the lesson to never enable CUDA support globally :upside_down_face:

Basically the release branch hasn’t been built yet/isn’t in the cache so you might need to build things yourself if you use it (and/or it might be broken).

1 Like

Thanks.

Mind if I say those are confusing tag names?

release-* is at least part of the reason, as it is the branch before hydra does the builds. You are running untested nixpkgs this way.

It might even hold unbootable kernels or bootloaders. This is a rare ocassion but it has happened in the past.

You really never want to use anything but a nixos-* prefixed branch to build a NixOS system!

3 Likes

Also, yes, using the cuda support config forces rebuilds of your browsers.

These were in fact the two differential diagnoses I’d have had if I’d have to make one without information (and what I meant when I was on about using channels without testing), they’re pretty common ways to cause this. I didn’t expect you to commit both :stuck_out_tongue:

HA I typed out asking if you enable cudaSupport, then deleted it when I saw the release-* channel thing.

There’s a binary cache for cuda which is mentioned in https://wiki.nixos.org/wiki/CUDA#Setting_up_CUDA_Binary_Cache.

1 Like