bug: firefox: read-only `profiles.ini` prevents initial launch on macOS

[montchr]

Are you following the right branch?

• [X] My Nixpkgs and Home Manager versions are in sync

Is there an existing issue for this?

• [X] I have searched the existing issues

Issue description

I initially started this report as a comment on #3302 but as I wrote, it started to seem like a related but distinctly separate issue without a clear workaround at this time.

Upon provisioning a fresh macOS system using an existing configuration, Firefox does not seem to accept the profiles.ini file generated by home-manager.

Here's the home-manager-generated file:

[General]
StartWithLastProfile=1

[Profile0]
Default=1
IsRelative=1
Name=home
Path=Profiles/home

[Profile1]
Default=0
IsRelative=1
Name=work
Path=Profiles/work

The StartWithLastProfile=1 setting stuck out to me as potentially problematic since any initial non-hm profile would necessarily be omitted from the generated file. Even if the profile directory technically still exists in the same place, Firefox will not pick it up and will refuse to open.

I moved the generated file away and copied its contents to a new file (with permissions 755), changing StartWithLastProfile to 0. After doing so, Firefox would load my default profile successfully. However, it also modified the file, with the new version looking like this:

[Profile1]
Default=0
IsRelative=1
Name=work
Path=Profiles/work

[Profile0]
Default=1
IsRelative=1
Name=home
Path=Profiles/home

[General]
StartWithLastProfile=0
Version=2

[Install2656FF1E876E9973]
Default=Profiles/home
Locked=1

Notable changes are the last few lines of that snippet. No idea what the Install2656FF1E876E9973 section is about...

This has been a frustrating issue for me on a newly-provisioned MacBook, and unfortunately the solution is not as simple as deleting profiles.ini. At the moment, it seems that the only workaround would require forking the module and modifying the output format for profiles.ini, since a rebuild of my home-manager configs would fail with my statefully-modified but working profiles.ini in the way of the declaratively-generated and broken(?) output from the home-manager Firefox module.

For context, I've been configuring Firefox profiles with home-manager on NixOS and a previous macOS system for a year or longer. Most of the NixOS systems I've configured have been born in the past few months, but it's been a long time since I've provisioned a fresh macOS system.

Maintainer CC

@rycee

System information

Firefox v105.0.3

- system: `"aarch64-darwin"`
 - host os: `Darwin 21.6.0, macOS 12.6`
 - multi-user?: `yes`
 - sandbox: `no`
 - version: `nix-env (Nix) 2.11.0`
 - channels(cdom): `"home-manager"`
 - channels(root): `"nixpkgs"`
 - nixpkgs: `/nix/store/h7skvhjn83cpx6ahmbaijvccbl4jl4sf-7cfzv30lr0jlyna80zgvj5gv5in352dz-nixpkgs-patched-for-aarch64-darwin`

Note: this is a flake-managed installation, and the nixpkgs version is essentially nixos-unstable but with two patches applied due to a couple upstream issues with PRs awaiting availability in nixos-unstable.

Relevant configuration:

https://github.com/montchr/dotfield/blob/17f53aff77fc5efb3a689a3f6b2219123229e943/home/profiles/firefox/default.nix

[montchr]

I've managed to get the home-manager-generated profiles.ini to work in the instance of Firefox I have been testing with (installed via brew install --cask firefox):

• Leave Firefox open
• Delete profiles.ini
• darwin-rebuild switch --flake <path/to/flake>
• Close Firefox
• Reopen Firefox successfully

That's great! However, when I try to open a newly-installed Firefox Developer Edition, I run into the same "missing profile" error as before.

Based on that observation, I'm guessing that each Firefox distribution wants to write to profiles.ini to add its own selection of a locked default profile. After reading through a couple threads on the Firefox support forums, I've gathered that the [Install...] section maps distinct Firefox installations to profiles.

After going through the same process of copying the contents of profiles.ini to a writeable file and re-opening Firefox Developer Edition, I am then prompted to select a profile. After doing so, the following new lines are added to profiles.ini:

[Install1F42C145FFDD4120]
Default=Profiles/home
Locked=1

FWIW, it also added back the corresponding section for the "Firefox" app.

So I run through the process of deleting profiles.ini + rebuilding + restarting Firefox DE, and it works, just like before with plain Firefox.

Despite each version attempting unsuccessfully to write to the profiles.ini in the store, once it manages to write to that file (after I allow it), Firefox also writes to installs.ini with almost-identical info mapping profiles to versions. Once it's able to finish doing so, it no longer seems to care about profiles.ini. Which is fine, but this is a really terrible workflow...

[mlyxshi]

Firefox linux verison works fine because the firefox wrapper sets MOZ_LEGACY_PROFILES=1

Under darwin, I use launchd to set the env

launchd.agents.FirefoxEnv = {
  serviceConfig.ProgramArguments = [
    "/bin/sh"
    "-c"
    "launchctl setenv MOZ_LEGACY_PROFILES 1; launchctl setenv MOZ_ALLOW_DOWNGRADE 1"
  ];
  serviceConfig.RunAtLoad = true;
};

[stale[bot]]

Thank you for your contribution! I marked this issue as stale due to inactivity. Please be considerate of people watching this issue and receiving notifications before commenting 'I have this issue too'. We welcome additional information that will help resolve this issue. Please read the relevant sections below before commenting.

If you are the original author of the issue

* If this is resolved, please consider closing it so that the maintainers know not to focus on this. * If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

If you are not the original author of the issue

* If you are also experiencing this issue, please add details of your situation to help with the debugging process. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

Memorandum on closing issues

Don't be afraid to manually close an issue, even if it holds valuable information. Closed issues stay in the system for people to search, read, cross-reference, or even reopen – nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.

[montchr]

I ran into this again the other day after wiping out the profiles trying to debug a separate unrelated problem. Totally forgot I had left a trail of advice in this ticket! But yes, still an issue.

[montchr]

@mlyxshi Why set those environment variables within a launchd service? Would something like home.sessionVariables, programs.<shell>.sessionVariables, or nix-darwin's environment.variables not work?

[montchr]

So, for more context, with the disclaimer that the following anecdote is not a home-manager problem (probably nix-darwin, but maybe the Nix installer…), but I figure it's worth the context of how the Firefox issue can happen on every boot:

I've noticed that the Nix Store volume does not become available on boot unless something (like a root-owned service) requests one of its resources/paths/binaries/etc… This is not a new issue for me (I've seen it happen since years ago) but I recently stopped using some of those nix-darwin services (skhd/yabai) and was surprised to see the unavailable store issue come up again. The worst side effect of this is that absolutely nothing from /nix/ is available until I open Finder (meaning no startup shell, no nix-provided software available in IDE, etc.)

[stale[bot]]

Thank you for your contribution! I marked this issue as stale due to inactivity. Please be considerate of people watching this issue and receiving notifications before commenting 'I have this issue too'. We welcome additional information that will help resolve this issue. Please read the relevant sections below before commenting.

If you are the original author of the issue

* If this is resolved, please consider closing it so that the maintainers know not to focus on this. * If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

If you are not the original author of the issue

* If you are also experiencing this issue, please add details of your situation to help with the debugging process. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

Memorandum on closing issues

Don't be afraid to manually close an issue, even if it holds valuable information. Closed issues stay in the system for people to search, read, cross-reference, or even reopen – nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.

[andar1an]

I am also having issues with this, though on NixOS. It would be great to be able to modify general settings in ini if not currently possible. Currently it seems tied to default logic. This also makes it not possible to select profile when opening a new browser every time.

[MattSturgeon]

I ran into this when trying to run the firefox flatpak on a system where home-manager has configured my firefox profiles.

I wanted to use the flatpak because I couldn't get hardware acceleration or video codecs working with the nix-firefox on a non-nixos host.

I was able to work around the issue by setting MOZ_LEGACY_PROFILES in my home.sessionVariables (see above comment). So far that seems to have resolved things for me.

[stale[bot]]

Thank you for your contribution! I marked this issue as stale due to inactivity. Please be considerate of people watching this issue and receiving notifications before commenting 'I have this issue too'. We welcome additional information that will help resolve this issue. Please read the relevant sections below before commenting.

If you are the original author of the issue

* If this is resolved, please consider closing it so that the maintainers know not to focus on this. * If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

If you are not the original author of the issue

* If you are also experiencing this issue, please add details of your situation to help with the debugging process. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

Memorandum on closing issues

Don't be afraid to manually close an issue, even if it holds valuable information. Closed issues stay in the system for people to search, read, cross-reference, or even reopen – nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.