Nix installation style is incompatible with Firefox's dedicated profiles per install feature

[Mossop]

Firefox is rolling out a feature where different installs of Firefox get a different default profile (https://blog.nightly.mozilla.org/2019/01/14/moving-to-a-profile-per-install-architecture/). The way it determines whether an install is different from another is based on the path of the installation directory. However I understand that Nix installs different version of Firefox in different directories so the feature will consider every version of Firefox to be a different install.

There are a couple of options I can think of to solve this:

• Always install Firefox to the same path. I imagine this goes against your policies so is unlikely to be a viable option.
• Disable dedicated profiles in your builds of Firefox, there is a configuration option (we'd have to expose it I think) to do this.
• Modify Firefox's mechanism for comparing install paths in your builds to support Nix, maybe by considering all installs under /nix/store to be the same install.

[garbas]

i think i just hit this myself when i updated to latest nightly. To comment on options you proposed:

• Always install Firefox to the same path. I imagine this goes against your policies so is unlikely to be a viable option.

This is actually not possible in Nix.

• Disable dedicated profiles in your builds of Firefox, there is a configuration option (we'd have to expose it I think) to do this.

I think this would be the most clean way to go ahead. since we can set custom prefs in out repackaging of firefox binary

• Modify Firefox's mechanism for comparing install paths in your builds to support Nix, maybe by considering all installs under /nix/store to be the same install.

This is not the case for nixpkga-mozilla repository since we only use binaries provided by mozilla. But we might escalate this to nixpkgs repo where firefox is built from source.

[rail]

I've been hitting this issue already for a week or two now. :) Every time when I upgrade Nightly (twice a day!) I get a new profile, unless I run firefox -P and select my profile.

@Mossop can you point me to the pref or the code that handles profiles?

BTW, maybe we should use the update channel name instead of the installation path to determine if we need to create a new profile?

[Mossop]

The code is all in toolkit/profile/nsToolkitProfileService.cpp. There is a way to opt out either by changing the build config or currently Snap packages are automatically opted out.

[rail]

I'm going to use this work around until we fix this. :) Let's see if it even works.

[Mossop]

If that works I'd prefer to add a different environment variable specifically for this (MOZ_DISABLE_DEDICATED_PROFILES or something) since the method for detecting Snap may be changing in the future.

[rail]

Yeah, it makes more sense to have an explicit env variable for this.

[rail]

Looks like it worked fine for me. I'll wait for another update tomorrow, just to be sure.

@Mossop BTW, how did you find this issue, I'm just curious. :)

[Mossop]

https://bugzilla.mozilla.org/show_bug.cgi?id=1527386

[rail]

Ah, thanks. @glasserc FYI^

[garbas]

@rail @Mossop so a quick solution for now would be to wrap binary with SNAP_NAME=firefox? and later (when available) we can change it to MOZ_DISABLE_DEDICATED_PROFILES or something.

[rail]

Yes, sounds correct to me. BTW, so far the hack works fine for me.

[Mossop]

Yep. I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1528082 on it, probably won't be able to get to it immediately though so if anyone wants to try working on it I'd be happy to help out!

[minojai]

Total layperson here, but can someone help me restore my bookmarks, add-ons, etc. in Firefox ever since the update for version 67.0.04 happened? But I need it explained in very basic terms. Thank you!

[garbas]

@minojai you basically need to set a system variable so that this (not-so-)new(-anymore) feature does not take affect.

either use SNAP_NAME="firefox" or from 68 on you can use MOZ_LEGACY_PROFILES=1.

[ekoudijs]

@garbas where do i need to place this solution? "MOZ_LEGACY_PROFILES=1" in the mozilla.cnf?

[garbas]

@ekoudijs in your environment.

[ekoudijs]

@garbas Is there somewhere any documentation how to do this? Thanks!

[garbas]

export MOZ_LEGACY_PROFILES=1

or even

MOZ_LEGACY_PROFILES=1 firefox

[ekoudijs]

Thanks

[sgraf812]

Not sure if this is the right place to report (I'll also report an issue on nixpkgs), but it appears that the firefox wrapper still passes SNAP_NAME=firefox today to fix FF 67 (https://github.com/NixOS/nixpkgs/commit/082ed38c), even though MOZ_LEGACY_PROFILES has long been available (and is also being passed since FF 69, https://github.com/NixOS/nixpkgs/commit/87e26184). For whatever reason, SNAP_NAME causes my firefox to suffer from abysmal intermittent delays, when creating, deleting or switching tabs, in particular, quite similar to https://bugzilla.mozilla.org/show_bug.cgi?id=1569625. I'm installing it through home-manager on NixOS with GNOME, but it shouldn't matter much (I tried to roll back to previous NixOS build where I still used none+i3, no difference). I'm following nixos-20.09 and it started failing with Firefox 87. I was using 85.0.1 before and everything was (and in fact, is) fine, even though the wrapper passed SNAP_NAME all the same.