Browser

Emanix ships Firefox, one browser, on graphical hosts. It is themed from the same palette as every other surface and it is not a default-application framework: there is no browser chooser and no xdg-settings ceremony to survive.

1. Launch it

Key Does
s-w Firefox
s-d The app launcher, which finds it too

s-w runs emanix/ewm-launch-firefox, which resolves a binary in three steps: firefox, then firefox-esr, then $EMANIX_BIN_DIR/firefox.

1.1. Your profile is not in the flake

The browser is declared; its contents are not. Bookmarks, history, saved logins, extensions and open tabs live in ~/.mozilla/firefox/default, which is runtime state. A rebuild neither creates nor restores any of it, so a new machine starts with an empty browser — the same boundary as wifi credentials in Network.

The profile path is pinned to the legacy location deliberately. NixOS's state-version-dependent default has moved to the XDG path, and the live profile is not there; following the default would strand it.

2. What the distribution sets

  • Chrome, from the active palette. userChrome.css is rendered by Nix at build time from config.emanix.theme.
  • Dark mode that agrees with it. ui.systemUsesDarkTheme follows the palette's variant, so Firefox's own UI and every prefers-color-scheme page do not sit dark underneath light chrome.
  • Wayland file handling. The XDG desktop portal is used for file pickers and MIME handlers, rather than Firefox's own dialogs.
  • A quieter new tab. Sponsored tiles and the default top sites are off.
  • One pref without which none of the chrome applies: toolkit.legacyUserProfileCustomizations.stylesheets.

Firefox is the one themed surface that is rebuild-time only. The terminal and Emacs can be switched live; Firefox renders exactly one palette and the runtime theme switcher cannot touch it. Changing it means editing emanix.theme and rebuilding — see Theming.

3. Page colours are left as authored

Chrome is themed. Page content is not. Forcing the palette onto content is a single pref (browser.display.document_color_use = 2) and it is the bigger accessibility lever, but it breaks sites that hardcode colours without honouring forced-colors. It is off on purpose, and the reasoning is recorded in the repository rather than here.

4. When there is no Nix Firefox

The third resolution step, $EMANIX_BIN_DIR/firefox, is a consumer-supplied wrapper. The distribution ships no bin/, so helper scripts come from the consuming flake and its directory is put at the front of PATH. The wrapper shipped with this deployment tries /usr/bin/firefox, then /usr/bin/firefox-esr, then flatpak run org.mozilla.firefox, and exits 127 with a message when it finds none.

That is the seam for a host whose browser is not from Nix — a machine with a distribution Firefox, or a WSL box reaching a Windows-side one. On a host where the distribution's own programs.firefox applies, the first step wins and the wrapper is never consulted.

5. Why not the FirefoxColor extension

The popular Catppuccin port themes Firefox by installing the FirefoxColor extension. That is more machinery than this needs, so the chrome CSS is generated instead. A catppuccin.firefox block did live here until 2026-08-09, gated on a flag that was never set and therefore never applied; it was removed along with the flake input nothing else used. The dark theme was never what that block did.

6. Ongoing

Rebuild with Build and Deploy; the palette is the only browser setting that a rebuild changes.