These new profiles that can be accessed through menu are not exactly sub-profiles, but I think more like sibling-profiles forming a profile group. Profiles in the same group know about each other, so in the UI you can switch between them and I think there are some settings that can be shared between the profiles in the same group.

I don’t know of any plans to deprecate the old profile system, nor about:profiles for managing them.

I would seriously suggest to at least check the last modified time of the file instead of constantly re-computing all the style rules every second. So at the very least:

// store last known modified time var previousModified = 0; setInterval(() => { // ... chromepath.append("userChrome.css"); // check last modified time before proceeding var modified = chromepath.lastModifiedTime; if(modified <= previousModified){ return } previousModified = modified; var chromefile = io.newFileURI(chromepath); // ...

I perceive the new profile system more as a extended capability of the old profiles than completely new and different thing. Although for a typical user it probably seems like a new feature since previously the profiles were quite invisible.

With new profiles, each profile will have a profile group they belong to, which means roughly “these profiles are linked”. Profile data is stored in separate directories just as before, but the linked profiles can open browser instances of each other and they can have some information shared between them, such as shared preferences, which is stored separately from the profiles themselves. I don’t think it’s there yet, but I believe you could then also have a profile-1 to open new tab in profile-2 etc.

Different Firefox versions can’t share profiles in the same group, so release Firefox has its own group, Developer Edition has its own group etc. In addition, I believe this new profiles capability is limited to “standard” profiles only, i.e. those that are stored in the default location and/or are reachable via profile-manager. They cannot be used with profiles loaded from arbitrary directories via command-line flags.

That Clear cookies and site data… button is only visible if there is data to clear. These screenshots indicate that searx.drgnz.club is not storing any data currently in Firefox, but startpage.com is storing some data in Librewolf - that is assuming that Librewolf also hides the item when there is no data.

I run nightly, not exclusively but pretty close, and I must say Firefox’ nightly builds are pretty damn stable in my experience. For sure, there are situations where some feature y is clearly unfinished, but it’s super rare to face a situation where I would even need to think about working around some issue - such game breaking issues just don’t happen too much at all. Usually, if a build is found to be truly broken (like crashes very often etc.) then nightly updates get paused. I can remember maybe two times that I’ve had to revert to previous build in over ten years because the I had received an update before updates were halted.

I don’t think there a way to open the library to history section via address. Library window history and bookmarks section are the same document, and the buttons that open open library window to history view do it by opening the window with extra window arguments - which you cannot do by simply changing the url.

A possible other option to show history would be to open Firefox view to history section. about:firefoxview#history

There’s also another thing that I don’t think is mentioned yet. The options available in Settings are supported features. If the feature is only available via about:config then there’s a good chance that it is not supported or tested configuration. It might work or it might not, at least not in all scenarios

A subset of “advanced” users might have turned telemetry off so it certainly is skewed somewhat, but I don’t think there a good reason for me to believe that the subset is necessarily that large.

You can hide them with userContent.css - most of the devtools window stuff is styled via userContent.css not userChrome.css.

But there’s a catch.

Browser toolbox is essentially a separate instance of Firefox, running in separate profile so your “normal” user css files don’t apply to it. Thus, you need to first enable the toolbox profile to load it’s own user css files and create them just like you do normally (toggle toolkit.legacyUserProfileCustomizations.stylesheets, create files in chrome/ folder etc.). The toolbox profile is stored inside the regular profile - in a directory chrome_debugger_profile.

To get to about:config of the toolbox profile you need to first open a new main-window for it - one way that works is to click the meatball menu at the top-right of the toolbox window, and select “Documentation…” - that will launch a new window using using the toolbox profile and then you can just open about:config and proceed as usual. Or you can just modify prefs.js of the toolbox profile directly while the toolbox is not running.

Anyway, after you have set up the toolbox window to load user css files, then just slap this to its userContent.css and restart the toolbox:

header.chrome-debug-toolbar{ display: none !important; }

Doesn’t really sound like a company that I would want to do any business with then.