When I upgraded from 66.0.5 it created a new profile, rather than keeping my existing passwords/histories/extensions.
I'm not going to use firefox sync, so it seems like there will be a painful migration ahead.
I'm not going to use firefox sync, so it seems like there will be a painful migration ahead.
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)
I consider myself a power user in many things, but never have I felt the need to run different versions of my browser simultaneously.
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! :-)
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.
> Sharing a profile between different versions of Firefox [...]
I was thinking different version numbers of the same Firefox installation (stable channel).
Profile-per-channel makes it much more clear, and makes sense.
That's a bug and is not supposed to happen.
Will this ever be possible?
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.
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!"
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...
I take a backup of ~/.mozilla and just download the new binaries to /opt/firefox. (Well I download and update a symlink.)
I'm not entirely certain, but if you want to source dive, nsXREDirProvider::GetInstallHash is a good place to start: https://searchfox.org/mozilla-central/rev/6c9f60f8cc064a1005...
https://groups.google.com/d/topic/mozilla.dev.platform/hVeJS...