Thanks, the " is wrong, in my case I use 'drop-indicator' and works fine. 💙

Oh, that code is for the Bookmarks Manager. Try this for the Bookmarks menu drop-down:

image[part="drop-indicator"] { background-color: white !important; }

First try and seem doesn't work.

I will try it without my theme soon. Seems like doesn't work, maybe is a change in Firefox beta, I test the code always in there to update my theme for the next version.

treechildren::-moz-tree-drop-feedback { background-color: white !important; }

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.

ooh, thanks for the information, your knowledge is epic. 🤝

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.

Seems like it solved now, thanks for all your help. 🤝

I hope they fix that, but seems like they don't want, thanks for your help. 💙

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

Thanks, that worked as intended. All playing together nicely now; great!

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.

So I'm not sure where that should be added; I tried adding it at the top of fake_statusbar_w_bookmarksbar.css, so the beginning code of that file, including some original code, now looks like this:
` #PersonalToolbar{ position: static; grid-row: 11/12; } :root:not([inFullscreen]) > body::after{ content: none; }

:root:not([inFullscreen]) > body{ --uc-statusbar-button-padding: 4px; --uc-browser-base-padding: calc(2 * var(--uc-statusbar-button-padding) + 16px + 4px); --uc-statusbar-text-vertical-position: 5px; } ` But it didn't change anything regarding tabs and statusbar, although the menubar is now back? Also, the gray bar at the top is still there. Then I tried adding that code to tabs_below_content_v2.css. with the same result.

So I moved the code back to fake_statusbar_w_bookmarksbar.css, and then in that same file I commented out this bit of code: /*:root:not([inFullscreen]) > body::after{ content: ""; display: flex; margin-bottom: calc(1px + var(--uc-browser-base-padding)) !important; order: 2; /* To make this really the bottom-most toolbar even with custom toolbar order */ }*/ Now things seem to be pretty much correct, although some of the sizing seems to be a little off. Previously, the tabs were slightly less tall. So now, with the tabs slightly taller, the tab rows don't completely fit within the height of the tab bar. How can I slightly reduce the height of the tabs?

Also, is what I did above the correct solution?

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;
}

Thanks for reply. So, primarily, there is a empty, gray horizontal band directly below the navigation bar, the entire width of the window. It is about the same height as the navigation bar. That, and the missing menu bar, were the real issues that I noticed yesterday. The status bar at the bottom seems correct; it has my extension icons on the right, and displays loading addresses on the left. However, today I also noticed that, although multi-row_tabs.css has --multirow-n-rows: 3; which is what I wish, yet I'm only seeing two rows of tabs at the bottom--it appears that the third row of tabs is hidden behind the status bar?

My userChrome.css is quite simple: it calls my_appearance_settings.css to set tab colours, and it then calls, in order, your three styles: multi-row_tabs.css tabs_below_content_v2.css fake_statusbar_w_bookmarksbar.css

If I comment out the fake_statusbar_w_bookmarksbar.css line, then the statusbar is of course gone, and that gray band at the top now has the extension icons (although they are near the left end rather than the right). Also, there are now three rows of tabs, and the scrolling seems correct. So perhaps the fake statusbar style is interfering with the tabs styles?

Hope that information helps.

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.

Thanks for the advice, and it works with @imports too (at least local files).

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.

Actually I got a .uc.mjs file working with the snippet that refresh every 1 sec: https://gist.github.com/jscher2000/ad268422c3187dbcbc0d15216a3a8060?permalink_comment_id=3259657#gistcomment-3259657

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.

This is a script for automatically refreshing the file: https://gist.github.com/jscher2000/ad268422c3187dbcbc0d15216a3a8060

Could I just plop it in as a <filename>.sys.mjs file with fx-autoconfig? https://github.com/MrOtherGuy/fx-autoconfig

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.

Indeed, my message wasn't very clear. While trying to keep my userChrome.css file up to date, I found this first commit and this second commit in your repository; I deduced that certain elements needed to be updated... but I was wondering which ones. I thought this was due to upcoming changes in Firefox, but I was probably mistaken...

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.