div.text-container { padding-block: var(--uc-container-block-padding, initial) !important }

Sure, if padding-block isn’t set then initial should be alright. I’m guessing the initial value would be 0px so it’s probably ok to not set any fallback value.

But there’s actually a rather recent value that you could use in place of initial - that is revert-rule. Whereas initial makes the property use it’s “browser default” value, using revert-rule as a fallback makes it use whatever it would have been without that custom style rule - so it would in this case revert to calc((var(--message-bar-container-min-height) - 1lh) / 2).

Similar to ::part, the :host selector is not usable from within userChrome.css. So I guess the only way here would be to make the things inside the shadow-root inherit some variables and use those:

.infobar{
  --uc-container-block-padding: 0px;
  --uc-close-button-block-margin: 0px;
}
moz-button.close{ margin-block: var(--uc-close-button-block-margin, 4px) !important }
div.container { padding-block: var(--uc-container-block-padding, 3px) !important }

This is a bit unfortunate complication, that could in theory break a bit if eg. eg.container elements would ever be outside of .infobar (which I don’t think is currently the case). But otherwise it should work just fine.

The flex value is a “factor” in a sense that it governs how much the available space is distributed for each element in a container. In the library toolbar there is normally only one item with flex - the spacer. In that case it doesn’t matter how large its flex factor is, because every non-zero number is “all there is”. If the filter input-box gets flex of 1 then the available space gets distributed evenly for the input-box and the spacer because now they both have flex factor of 1. But if the input-box has flex factor of 1000, then 1000/1001 of the space is distributed for input-box and only 1/1001 for the spacer, effectively making it so that the spacer shouldn’t appear to grow at all - not until the input-box reaches its maximum width if it has any.

In the Library, is it possible to reduce the space between the toolbar

I think what you want to do for the Library toolbar is to make the search input box flex more that the spacer space:

#searchFilter{ flex: 1000 !important }

However, the Library’s tooltips still have a border. Is it possible to remove it?

You can, but not by using userChrome.css. Tooltips in Linbrary window, as well as some within main browser window are using native anonymous content which userChrome.css doesn’t apply to. You need to have some way to load a style sheet as user agent sheet - which is only really possible by building Firefox yourself or injecting the style using autoconfig feature.

Like this maybe? Setting short duration should be safe so that if there is logic that waits for animation to end then this (probably) won’t break it:

:is(#downloads-indicator-start-box, #downloads-indicator-finish-box) > .toolbarbutton-animatable-image{
  animation-duration: 1ms !important;
} 

Something simple like just .tab-stack{ transform: scale(1.2) } might work mostly fine. But I think it might lead to some small overflow problems. Alternatively you could try this:

#tabbrowser-tabs[orient="vertical"]{
  --uc-tab-icon-size: 24px; /* modify this to change tab icon size */
  --tab-min-height: max(calc(24px + (var(--uc-tab-icon-size) - 16px)),calc(1.7 * 1em));
}
#tabbrowser-tabs[orient="vertical"]:not([expanded]) .tab-background{
  margin-inline: auto !important;
  width: calc(var(--tab-min-height) + 2px) !important;
  aspect-ratio: 1;
}
.tab-icon-image{
  width: var(--uc-tab-icon-size) !important;
  height: var(--uc-tab-icon-size) !important;
}
#tabbrowser-tabs[orient="vertical"]:not([expanded]) .tab-content{
  padding-inline: 0 !important;
  margin-inline: auto;
}
#tabbrowser-tabs[orient="vertical"]:not([expanded]) .tab-close-button{
  inset-inline-start: calc(16px - var(--uc-tab-icon-size)) !important;
}

The tab scrollbar you can probably make bigger simply like this:

#tabbrowser-arrowscrollbox[orient="vertical"]{
  --uc-scrollbar-width: auto;
}
scrollbox[orient="vertical"]{
  scrollbar-width: var(--uc-scrollbar-width) !important;
}

Is it possible to remove this button when there is only one (or no) search engine in the submenu?

I don’t think that’s possible. At least, not exactly how you you described it. You could get pretty close like this:

#urlbar:not([searchmode]) > .urlbar-input-container > .searchmode-switcher{
  margin: 0 !important;
  padding: 0 !important;
  max-width: 8px;
  overflow: hidden;
  opacity: 0;
}
#urlbar > .urlbar-input-container:has( > .searchmode-switcher-panel > #searchmode-switcher-panel-list-urlbar > panel-item + panel-item) > .searchmode-switcher {
  max-width: unset;
  opacity: 1;
}

However, when you disable or enable search-providers, the state of the panel only updates when it is shown the next time. So if the panel had only single item and thus it is not shown, and you go to settings and enable another one, then the button will stay hidden until you open the panel once - which is a bit tricky since the button is hidden.

As for the separators, they seem to have their margin set with !important your userChrome probably won’t override it. But luckily the value is set to var(--space-small) so you could possibly just modify that. Something like this:

panel-list > hr{
  --space-small: 0;
}

Add !important tag to the fill property - menu.css in Firefox 149 specifies a fill property for those elements so you now need to override that.

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.