The new profile management system is fundamentally broken. Please fix it.

[daddiofadio]

I’m a software developer who switched to Firefox from Chromium about a year ago. I genuinely love Firefox, both as a developer and as an everyday user, and I appreciate the work that goes into it. That said, the new profile management system is fundamentally broken. I've never posted here before, but thought it was important because multiple developers I’ve spoken with have independently run into the same problems without any prompting from me. One of them also pointed out that it's issues like this that ultimately influence whether Firefox is seriously considered for broader adoption. 

The core of the issue is that Firefox now has two profile systems with overlapping goals and zero interoperability. Profiles created via the new toolbar-based profile manager are not compatible with those created in about:profiles or the -P switcher, and profiles created via the legacy system do not appear in the new manager. They coexist, but they do not communicate.

For power users, this is especially frustrating. The old profile manager allowed profiles to live in custom directories and could be manipulated through profiles.ini, command-line flags, etc. But, instead of extending the existing system, Firefox for some reason introduced a parallel one with fewer configuration options and no supported way to reconcile the two.

Developers, however, are affected the most. As I'm sure the developers here know, a typical workflow involves multiple isolated Firefox profiles, each with different extensions, preferences, and devtools settings, stored in predictable custom directories so they can be launched from VS Code or other editors. It is also common to open development profiles side by side with normal browsing profiles for instant visual comparison. Whereas the old system supports all of this, the new system does not.

What makes this particularly frustrating is that I can almost make it work, but it appears Firefox engineers intentionally designed it not to. The new profile manager uses an SQLite database under the "Profile Groups" directory. I was able to manually import legacy profiles by inserting rows into the Profiles table, for example:

INSERT INTO "Profiles" VALUES (
  4,
  'Profiles\qnx7k4eh.test',
  'profile',
  'briefcase',
  'firefox-compact-dark@mozilla.org',
  'rgb(251, 251, 254)',
  'rgb(43,42,51)'
);

At first glance, it works. Profiles created with the old system show up in the new manager, it bypasses the issues with profiles.ini, etc. However, it only works if the profile lives under Firefox’s default profile directory. As soon as the profile exists in a custom path, the new manager refuses to recognize it. Absolute paths and relative traversal paths fail. The database even stores external paths in traversal form like "..\..\..\..\custom\path\profile.default," which strongly suggests the path field is validated and constrained to remain inside a managed root.

This is where the design completely loses me. The new system appears to intentionally restrict all profiles to a single directory with no supported override. The single most important feature for power users, choosing where their data lives, was deliberately removed.

Developer Edition makes this worse. The new profile manager forces Developer Edition and Stable to share the same default profile root unless you use the old profile manager. Users cannot cleanly separate everyday browsing profiles from development profiles unless they commit to using two different, incompatible profile management systems. Firefox developers, of all people, should have anticipated that users running Developer Edition do not want profiles mixed with daily browsing, expect separate or at least configurable roots, and are more likely to need automation and custom directory layouts.

The only partial workaround I have found is using a directory junction. This preserves compatibility with the new manager while allowing a custom directory layout, but it only works on NTFS. If you need cross-platform portability, for example a profile on an exFAT drive shared between Windows and Linux, you're still out of luck.

This is not a case where Firefox made a tradeoff to serve one group at the expense of another. If there were a fundamental conflict between a simple system for casual users and a flexible system for developers, that would be understandable. But introducing a new profile management system that cannot see profiles created by the existing one, does not interoperate with -P or about:profiles, cannot support custom directories, and actively blocks common developer workflows makes no sense. Users are forced to choose between control and convenience, and developers get neither.

I'm hoping someone here with more insight can shed light on why Firefox chose to implement it the way they did and if there is any plan to unify the legacy and new systems, or allow custom profile paths in the new manager.

[dwhaley720]

What's also annoying is when trying to modify or delete a profile from the new profile manager window, it launches that profile and makes you change the settings (or delete it) from inside it, instead of just letting you modify it directly from that window. And for some reason, when you import the old profiles into the new system by modifying the SQLite, those special pages like about:deleteprofile or about:editprofile simply do not work in those profiles and just show blank pages, even when they have the new profile manager feature flags enabled in about:config. What's worse is if I or some external force manages to delete that profile from my file system manually, it'll still show up in the manager. And when you attempt to launch it, it just creates a new blank profile with those pages still broken! I'm honestly baffled as to what's going on here.

[daddiofadio]

Yes, I have run into all of the issues you describe as well, and I continue to see new, related posts on a regular basis.

I was specifically directed to post here by other developers in different Mozilla communities, which suggested this would be the best place for developers to respond. Hopefully, at some point, a Mozilla developer can provide at least a brief acknowledgment of this post and any possible workarounds. In the meantime, I have effectively given up on the new profile manager and am using the legacy manager exclusively.

[jhirsch]

@daddiofadio Hey, thanks so much for reaching out here! I led work on the new profiles UI and replied to your post on r/firefox, but over the winter holiday break I discovered I had been shadowbanned. I hadn't seen your comment here, but Jon (the community manager) just pinged me with the link. All of this to say - sorry I haven't replied sooner, and thanks for being such a passionate Firefox user. I recognize it took a lot of time and energy to write out your questions and concerns in this level of detail.

I want to address some of the high-level concerns first, and then I'll address your specific questions in more detail.

First and foremost - the new multiple profiles UI is not replacing the existing profiles system. It's a more user-friendly addition that preserves backwards compatibility. We are keeping the existing toolkit profile service code in place to support existing power user, QA tester, etc. workflows. The relationship between the existing toolkit profile service and the new selectable profile service (naming things is hard...) is somewhat complex because we are ensuring backwards compatibility with prior versions of Firefox, and we didn't want to risk regressing startup time by making major changes to the early startup-time C++ code.

Second, you've bumped into some bugs in the implementation that we're currently working to fix. In particular, the bug to allow absolute paths for selectable profiles is just landing today (https://bugzilla.mozilla.org/show_bug.cgi?id=1994700). There's also a bug in flight (https://bugzilla.mozilla.org/show_bug.cgi?id=1996240) to add a "migrate" button to each profile entry in about:profiles so that you can easily merge existing toolkit profiles into a selectable profile group. I'm between meetings but will add some bug numbers in a bit. 

Unfortunately I'm running to another meeting right this minute, but I'll add more of a response later today. In the meantime, you can read more about the profile system here: 

• https://firefox-source-docs.mozilla.org/toolkit/profile/
• https://firefox-source-docs.mozilla.org/toolkit/profile/changes.html 

[jhirsch]

OK, finally have a minute to respond more directly.

---

@daddiofadio wrote:

I’m a software developer who switched to Firefox from Chromium about a year ago. I genuinely love Firefox, both as a developer and as an everyday user, and I appreciate the work that goes into it.

🙂 thanks!

The core of the issue is that Firefox now has two profile systems with overlapping goals and zero interoperability. Profiles created via the new toolbar-based profile manager are not compatible with those created in about:profiles or the -P switcher, and profiles created via the legacy system do not appear in the new manager. They coexist, but they do not communicate.

For power users, this is especially frustrating. The old profile manager allowed profiles to live in custom directories and could be manipulated through profiles.ini, command-line flags, etc. But, instead of extending the existing system, Firefox for some reason introduced a parallel one with fewer configuration options and no supported way to reconcile the two.

(snip)

---

This is where the design completely loses me. The new system appears to intentionally restrict all profiles to a single directory with no supported override. The single most important feature for power users, choosing where their data lives, was deliberately removed.

---

As I mentioned in my earlier reply, this wasn't a deliberate decision, it's just a bug, and it's been fixed in Nightly 148, which will ship to the release channel audience in late February.

---

This is not a case where Firefox made a tradeoff to serve one group at the expense of another. If there were a fundamental conflict between a simple system for casual users and a flexible system for developers, that would be understandable. But introducing a new profile management system that cannot see profiles created by the existing one, does not interoperate with -P or about:profiles, cannot support custom directories, and actively blocks common developer workflows makes no sense. Users are forced to choose between control and convenience, and developers get neither.

I'm hoping someone here with more insight can shed light on why Firefox chose to implement it the way they did and if there is any plan to unify the legacy and new systems, or allow custom profile paths in the new manager.

---

There is a fundamental conflict between the old ToolkitProfileService (which powers about:profiles and uses the profiles.ini file) and the new SelectableProfileService (which powers the new Profiles menus and stores its data in SQLite), and it turns on the need for concurrent access to profiles data.

Consider the product requirement that the list of profiles shown in the Profiles menu needs to be consistent across multiple instances of Firefox running at the same time, even if, for example, one of the profiles has just had its name changed. To satisfy this requirement, we can't use a file-based datastore like profiles.ini, we need a datastore that supports concurrency. SQLite is the natural choice: it supports multiple reader / single writer semantics through WAL mode, and it's already available for us to use internally in Firefox.

On the other hand, we couldn't simply get rid of profiles.ini and move everything into a SQLite database, because we wanted to avoid breaking existing power user workflows, preserve backwards compatibility with earlier versions of Firefox, and avoid regressing startup performance. So we do still need to keep some data in profiles.ini, and we need to continue to use the ToolkitProfileService to select a profile at startup.

-----

It's getting a bit late here, so I'll probably stop at this point. But for folks on the thread, what else do you find confusing about the relationship between the new and old profiles systems? What would you like to be able to do, either at the command line or in the UI, that you can't currently do? I'm happy to take suggestions here or in bugzilla bugs (you can file a bug here). The team working on profiles has been reassigned to other projects, but we can still carve out time to fix bugs and make changes to better support power users.

[jhirsch]

Update: the fix for custom profile locations will ship next month in firefox 148: https://bugzilla.mozilla.org/show_bug.cgi?id=1994700

This will hit release in late February: https://whattrainisitnow.com/release/?version=148

[cassepipe]

Hey @jhirsch !

I just wanted to say thank for taking the time to give technical explanations to the current design choices (constraints mostly 🙂

Even though I know deep down that some frustrating design choices have underlying technical constraints, it really helps psychologically to hear about what those constraints were. 

I wish firefox's communication was better on this front but I guess devs don't have the time to make writeups and communicants don't reallly understand technical choices ? 

I really hope that the work of fusing the old profile system into the new one gets done even though it seems the people working on it have moved on. 

It's not the subject of this thread but is the problem of custom-search-keywords-as-bookmarks and the custom-search-keywords-as-search-string-in-the-settings of the same nature ? A file based system vs. a sqlite based newer system ?

It's be really nice if the former were synced like bookmarks are...

Anyways, hope to read you again in the future