Problem with about:profiles page
Unimportant and mildly disruptive issue: I've been using the about:profiles method to maintain separate profiles. I am aware that this is distinct from the new way to manage profiles (about:profilemanager; https://support.mozilla.org/en-US/questions/1543697 ).
I normally use my default profile (let's call it profile A) to open other profiles (of which there are 6 + a Nightly profile).
However, recently I've noticed that if I open another profile (B) from profile A: Refreshing profile A's about:profiles makes it inactive, with the "Another copy of Firefox has made changes to profiles" error. Now, B's about:profiles correctly displays the different profiles, and I can launch more profiles from here. But A is still shown as the default profile. I've tried this with a few other profiles (C, D), but even with those open, B still seems to have the functional about:profiles page.
Is there any way to reset this, i.e. to make A's about:profiles functional even when profile B is launched?
Edit: I think this is because profile B has the new profile manager enabled, and under this, B is the original profile. I tried setting browser.profiles.enabled to false in the about:config settings but this doesn't seem to help. Oh well!
Ändrad av applover9141
Vald lösning
Hi applover9141, thanks for the clear write-up — you’ve already dug into this deeper than most
What you’re seeing is essentially expected behavior once multiple profiles are running, and it’s tied to how Firefox handles profile locking and the newer profile manager.
A few key points to clarify what’s going on:
about:profiles is not designed to be “live” across multiple running profiles. Once you launch profile B from profile A, profile A loses its exclusive lock on profiles.ini. When you refresh about:profiles in A, Firefox correctly reports that another copy has made changes and disables management from that instance.
Only one running profile gets a “functional” about:profiles UI at a time. In practice, this ends up being whichever profile Firefox considers the primary/original one under the current profile manager logic — which aligns with your observation that B becomes the functional one.
Your suspicion is likely correct: When browser.profiles.enabled (new profile manager) is involved, Firefox internally treats one profile as the “owner” of profile management. Toggling the pref back to false doesn’t fully revert behavior once profiles have been initialized under the new system.
Is there a way to “reset” this?
Unfortunately, not cleanly or officially.
There is:
No supported way to make multiple concurrently running profiles all have an active about:profiles
No reliable pref or config reset that restores the old behavior once the new manager has been engaged
Practical workarounds
What you can do instead:
Designate one profile as your “launcher” profile and always open others from there (closing it last)
Or use command-line profile launching (firefox -P or -profile <path>) instead of relying on about:profiles
Or accept that whichever profile is started first will usually be the one with the functional profile management UI
So in short: this isn’t a bug so much as an architectural limitation + transition side effect between the old and new profile systems.
Your conclusion of “oh well” is, unfortunately, pretty accurate — but your diagnosis was spot on
Läs svaret i sitt sammanhang 👍 1Alla svar (2)
Vald lösning
Hi applover9141, thanks for the clear write-up — you’ve already dug into this deeper than most
What you’re seeing is essentially expected behavior once multiple profiles are running, and it’s tied to how Firefox handles profile locking and the newer profile manager.
A few key points to clarify what’s going on:
about:profiles is not designed to be “live” across multiple running profiles. Once you launch profile B from profile A, profile A loses its exclusive lock on profiles.ini. When you refresh about:profiles in A, Firefox correctly reports that another copy has made changes and disables management from that instance.
Only one running profile gets a “functional” about:profiles UI at a time. In practice, this ends up being whichever profile Firefox considers the primary/original one under the current profile manager logic — which aligns with your observation that B becomes the functional one.
Your suspicion is likely correct: When browser.profiles.enabled (new profile manager) is involved, Firefox internally treats one profile as the “owner” of profile management. Toggling the pref back to false doesn’t fully revert behavior once profiles have been initialized under the new system.
Is there a way to “reset” this?
Unfortunately, not cleanly or officially.
There is:
No supported way to make multiple concurrently running profiles all have an active about:profiles
No reliable pref or config reset that restores the old behavior once the new manager has been engaged
Practical workarounds
What you can do instead:
Designate one profile as your “launcher” profile and always open others from there (closing it last)
Or use command-line profile launching (firefox -P or -profile <path>) instead of relying on about:profiles
Or accept that whichever profile is started first will usually be the one with the functional profile management UI
So in short: this isn’t a bug so much as an architectural limitation + transition side effect between the old and new profile systems.
Your conclusion of “oh well” is, unfortunately, pretty accurate — but your diagnosis was spot on
Hi Nathan, thanks for taking the time to reply and clarify what is happening!
Another workaround which I've tried in the meantime, but which involves losing profile data, logins etc.:
I've simply deleted profile B (along with profile data) from profile A (the default). Then I've created a new, replacement B profile from A's about:profiles and set A as the default profile. Then (I think) I launched replacement-B, and set its 'browser.profiles.enabled' flag to false. Now everything works as expected (so far): A's about:profiles remains active even after launching replacement-B.
(Trying to delete profile B from itself does not work, because Firefox then tries to create a replacement default profile under the new profile system, causing the same problems. We don't want this, because we want the old [or a consistent] profile system, and for profile A to be the default.)
Ändrad av applover9141
Du måste logga in på ditt konto för att svara på inlägg. Vänligen starta en ny fråga om du inte har ett konto ännu.