SelectedItem is just a normal(*) keyword value for color like white, black, red etc. So yes, you’ll need to set it wherever it’s used.

* Not entirely true, it’s system color keyword and it happens that you can use prefs to set value for system colors. Go to about:config and create a new string pref ui.selecteditem and set it to #ff0000 and it should become red.

This seems to be a recent regression in nightly - I created bug 2011219 for this.

If you are using @import statements in your userChrome.css to load the other files, then I would put these extra rules at the end of userChrome.css after the imports.

For the tab heights, none of the styles should be modifying the tab height, they should be as tall as they are in Firefox normally. Make sure you are not setting tab height related properties in my_appearance_settings.css.

Edit: I mean, you can edit tab heights, you just need to do it in a manner that is compatible with multi-row_tabs.

Oh right, I missed that you were also using fake_statusbar_w_bookmarksbar.css - that’s totally not compatible with tabs_below_content_v2.css

You can add this bit to make them behave together:

#PersonalToolbar{
  position: static;
  grid-row: 11/12;
}
:root:not([inFullscreen]) > body::after{
 content: none; 
}

Or if you want tabs to be below that fake statusbar then add this as well:

#TabsToolbar{
  grid-row: 12/13;
}

There was something to do with menu bar in multi-row_tabs_below_content.css, so I replaced that file with the latest versions of the two new replacement files, multi-row_tabs.css and tabs_below_content_v2.css. This did indeed restore the menu bar, but it broke tab bar scrolling (and a few other incidentals).

multi-row_tabs.css + tabs_below_content_v2.css is indeed the intended method to achieve what you are after (at least, if you are using my styles). I don’t have normal ESR 140 installed, but with Tor browser, which is based on it, when tabs span over the maximum number of lines then they scroll as intended using mouse wheel. What are the “few other incidentals”? Perhaps that might yield a clue about why it isn’t working on your system.

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.