We're defaulting to profile-per-install to make it easier to run different versions side-by-side, but you can still manually specify your original profile.
1. People do genuinely seem to find it useful (it's been a feature in Developer Edition for years), so that's cool, but also...
2. Sharing a profile between different versions of Firefox can cause data loss, and profile-per-install makes it harder to accidentally make that mistake.
So it's win-win. As for why people find it useful, I've mainly seen two camps:
- People who want to keep their work and personal browsing separate.
- Developers who want to maintain a pristine / default browser environment for testing, and a customized one for development.
I've also, on occasion, seen normal people with separate browsers for specific tasks (only using Facebook in Opera, only banking in Firefox, etc.) Now those can all be different foxen! :-)
I see the use case for developers who want to test multiple versions.
But as stevekemp said, the average user is losing their profile when simply upgrading from one version to the next. And it seems that the fix to this is to go back into the Profile Manager and set you old profile as the new default. Wouldn't this inadvertently cause data loss for the average user? (Ex: My parents do not even know Profile Manager is, much less that Profiles exist)
If anything, I see this as a bad thing - especially for those who do not use FF Sync. Am I interpreting this correctly? We're talking about regular FF here, not Developer Edition, correct?
Edit:
> People who want to keep their work and personal browsing separate.
I thought that's what Multi-Account Containers was supposed to help with.
Not quite. In the normal case, users will never see any difference as a result of this change. Most users will experience it, semantically, as "profile per channel," separating normal Firefox from Firefox Nightly, etc. And if you only use stable Firefox, you only have one profile.
That means that upgrading from Firefox n to Firefox n+1 is totally fine and it will continue to use the same profile. But installing Beta or Nightly will now default to using a separate profile, instead of trying to use the same local data as normal Firefox.
I suspect Steve's issue is because he's unpacking his new version of Firefox to a different location on disk, so we're treating it like a separate install, rather than an upgrade of an already installed Firefox.
As I understand it, this only affects running different official builds side by side. But what about running two different instances of a single build side by side with different profiles? The use-case I'm thinking of is something akin to Site Specific Browsers (SSBs), where each site has its own dock icon etc.
That actually is possible, but you have to manually create the shortcuts.
Check out https://support.mozilla.org/en-US/kb/profile-manager-create-... for docs on the profile manager. Once you've set up the profiles you want, you can launch a specific profile by passing "-P profileNameHere" or "--profile /path/to/profile" to Firefox.
You may also need to pass "--new-instance" or "--no-remote" to force Firefox to launch a new window if another copy of the same Firefox version is already open.
Additional use case: I sometimes give prerelease versions a try to report bugs, without intending to use it as my default browser (especially if bugs are blockers). It's nice to be able to get back to my regular install in that case.
Go to "about:profiles" and make your old profile ("default" by default) the default profile again, then restart Firefox.
This was indeed a fucking terrible way of doing this: "Hey, we've just hidden all your profile data from you and to get it back you need to sign up to our web service!"
That's really odd. Had you used that profile with a post-67 nightly at some point or something?
Some more information about the profiles involved here would be really useful. Are you willing to file a bug at https://bugzilla.mozilla.org/ ? If you do and give me the link to it, I'll get people who know the right questions to ask involved...
We might be resolving symlinks to their physical paths, making each download look like a new install. If so, the nixpkgs issue I mentioned above is probably more relevant than expected.
It looks like that may be related to FF now creating a separate profile for every installation. That was apparently targeted for FF65 originally, then bumped to FF67:
Docs on the profile manager are at https://support.mozilla.org/en-US/kb/profile-manager-create-...
...or, as a super weird hack, you can set the envvar SNAP_NAME=firefox to get the old behavior (see https://github.com/mozilla/nixpkgs-mozilla/issues/163 for context)