I can’t speak how Firefox devs intended it, but in my mind the new profile system is more of an “additional feature available for profiles in the managed profiles directory” - not a replacement for “real” profiles. In my tools, I’ve always linked to additional profiles using firefox --profile path/to/profile thus they are not listed in profiles.ini anyway (or at least they don’t need to be) and this still works fine wherever that directory happens to be located in.

Sure, you can apply reloading like that if you want. But I would be careful when using that as .uc.mjs because if you don’t tag that script with @onlyonce - and you have like 10 windows, then Firefox will reload userChrome.css once a second for each window so potentially 10 times a second. That could be quite a lot of cpu usage for constantly invalidating and computing the browser UI styles.

Also, I don’t think that function can handle the case where you use @import statements in your css.

Well you can, but it would only run (and thus reload) once very early on startup, which is probably not what you want.

If you use fx-autoconfig, it also has a helper function for loading userChrome.css (or other stylesheets) that you can call like this: UC_API.Scripts.reloadStyleSheet()

Still, the complex part is in figuring out when exactly you want to do the reloading. For example, you coud set it up so that it get reloaded when hitting some hotkey (Ctrl + F8 in this example):

import { Scripts, Hotkeys } from "chrome://userchromejs/content/uc_api.sys.mjs";
Hotkeys.define({
  id: "reload-userchrome",
  modifiers: "ctrl",
  key: "F8",
  command: () => {
    console.log("reloading...");
    Scripts.reloadStyleSheet()
    
  }
}).autoAttach()

Adding that as <filename>.sys.mjs should work (unless something else on your system is stealing the Ctrl+F8 shortcut). Note, even though the styles should get reloaded, the window might not re-render immediately - which may require you to move your mouse or do some other stuff before you see the changes.

The simple solution would be to do your edits using browser toolbox - that should get reloaded “live” while you edit it.

But if you truly want Firefox to reload the file while some external editor is modifying it then that’s going to require some serious hackery. Like, writing you own custom functionality using autoconfig that would poll the filesystem for changes for userChrome.css and the reload it if file modification date changes. I donmt see why it wouldn’t work, but it’s pretty stupid if you ask me. More sensible would be to have a button which reloads the file when clicked - this would of course need to be created using autoconfig as well.

Sorry, I couldn’t reply earlier. Yeah, so indeed searchbar is getting an update where it would use same kind of structure that urlbar is using - not sure in what version it will land in release Firefox though. The point of those extra :where(#urlbar) selectors in those commits is that some of the rules in the affected sites should only apply to things which are inside urlbar.

If you don’t have a separate searchbar enabled then you don’t necessarily do anything. Also, if you do use separate searchbar you might actually want to apply some of the rules also to it as well to have it styled consistently to urlbar. It all depends on what you want do achieve, really.

Sorry, but I don’t quite understand what you mean. You don’t know what kind of changes are going to happen in the future - and neither do I, so we can’t future-proof any rules too much. The selector :where(#urlbar) > only means that the selector coming after it must also match the element that is a child of urlbar even if the selector would also match something else in the document. I suppose it would be somewhat relevant currrently, since similar class names are also used in the searchbar popup now or soon (depending on what Firefox version you are using) and you might only want to affect things inside urlbar but not inside searchbar.

Sure, you can add this:

#navigator-toolbox{
  transition: margin-bottom 135ms ease-in var(--uc-autohide-toolbar-delay) !important;
}
#navigator-toolbox:is(:hover,:focus-within),
#mainPopupSet:has(> [panelopen]:not(#ask-chat-shortcuts,#selection-shortcut-action-panel,#chat-shortcuts-options-panel,#tab-preview-panel)) ~ #navigator-toolbox{
  margin-bottom: 0 !important;
  transition-delay: 100ms !important;
}

You could probably get things wayy simpler than what that style is doing if you want web-content to move, although it probably still won’t be quite trivial. But adding the above after autohide_bookmarks_and_main_toolbars.css should work fine I guess.

Some of it is stuff that I have found out about when folks have reported that this or that style is broken after some update (which might be update in pre-release versions). I also occasionally scan through changes in nightlies - via this page and it’s not super uncommon that some change rings sounds like something that could affect one of my styles - so then I’ll usually check it out more thoroughly. And of course it can happen that one of the styles I’m using (which isn’t very many tbh) changes behavior after nightly updates.

Might sound like a lot, but it really isn’t too much effort. Responding to changes is usually quite simple, its way more work trying to figure out how to reproduce some problem that someone else if having but which only occurs under specific conditions.

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.

Go to about:config and create a new number pref ui.systemUsesDarkTheme and set it to 1

Hi, urlbar-background is not an id anymore but a class. So use .urlbar-background instead.

I can’t say much about the color-scheme issue though, but it sounds like for some reason Firefox isn’t getting the information from your OS.

FYI, I just tested this in Firefox Nightly and I don’t see any abnormal cpu use with that either.

I’ll take that back. It didn’t happen at first but after a short while it totally trashed my cpu and made that Firefox window mostly unusable. I tried to profile it to see what’s eating the cpu but couldn’t really find the culprit - what I did see though, is that the “overflow” button in the sidebar was flickering like crazy - this suggests that Firefox is constantly computing new the layout for the sidebar.

You do mean the buttons are that is at the bottom of the sidebar when vertical tabs are enabled, right?

Your code doesn’t cause any cpu issue on my system, but I would bet that if it does, it’s because your code makes the buttons appear and reappear causing Firefox to constantly compute new layout and update the elements accordingly.

Tough to say without being able to reproduce the problem, but some possible things that might help would be to use visibility: hidden instead of collapse.

Damn, I’m an idiot - I looked for the wrong thing in the source. But yes, apparently the quit-button isn’t there on macOS, for whatever reason.

That works, thanks. I assume you are adding icons to items with css, but there is not supposed to be a restart item there either. Not in normal Firefox.

Well, the imgur link is just a blank white image so that doesn’t help, but I find it really odd if the main panel menu wouldn’t have quit/exit option on macOS. Also on a quick search on the source I don’t find anything to indicate that it would be hidden on macOS. Same goes for the About:Firefox item in Help panel.

I have no clue about macOS really, but I think it’s super odd that these two would be missing - are you sure you have a official version of Firefox installed and not some third-party build or fork?

The border image is set for the ::before pseudo-element of that separator, so #appMenu-fxa-separator::before { border-image: unset !important; } should work.

On my system, there is no separator between find in page and translate page. Perhaps the line you have there is something you have added yourself?

Firefox uses OS native context menus on MacOS, so the context menus cannot be styled with css. I suppose that could also mean that they can’t be prevented from disappearing on click when disable popup autohide is active. I would guess that other popups (such as the urlbar popup or main menu popup) are still disabled from autohiding - if not, the you should probably report that as a bug.

This doesn’t sound possible. There is specific code in Firefox to scroll the horizontal tab strip to a position that shows selected tab but that of course only works with how horizontal tab strip is normally. Or in the case of built-in vertical tabs there is code to scroll vertically when tab is selected. But with the hacky vertical tabs, as far as Firefox’s logic knows, it is still a horizontal tab list and the logic doesn’t work. And with multi-row tabs the scrollable container is just totally different element than what’s normally used.

Looks like that style just needed a few updates. Should be all good now.