I understand that there will be other changes to certain elements, including the address bar, in future versions of Firefox: to which selectors should I add :where(#urlbar) > to ensure that my code is compatible with future versions?

Thank you very much for your help!

I'm OP, replaying to this with my alt becuse monyet is so slow.
Firstly thank you. This works well. But sometimes if one hovers for a small amount of time the toolbars do not transition all the way down, and get stuck midway until they disappear after the specified autohide delay.

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.

OK, thank you for the tips!

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.

Thanks for the tip. It works!

urlbar-background is not an id anymore but a class

May I ask how you keep up to date with these kinds of new features? Do you review the new features page when a new version of Firefox is released? Is there an easy way to find out about these changes in advance?

In any case, you have (once again) been a great help; thank you very much, and have a nice day!

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.

Thanks for the info. I always have trouble finding this kind of information. I took a look at the latest commits on your GitHub repository, but I didn't see anything noteworthy...

I can’t say much about the color-scheme issue though

The problem is that choosing the "Dark" theme instead of the "System theme - auto" gives a very different result... Is there a way to force the dark mode of the "System theme"?

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.

hi, I notice the issue happens when the #sidebar-main is 'expanded', when collapsed the problem doesn't appear, I removed the code gap: 0px !important; and that solve the issue, but that space between the buttons makes me nervous jeje I tried delete too that 'overflow' button to remove the 'flickering' but the problem persist.

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.

I'm personally adding that code for a smooth transition, so I don't want to remove it.

I forgot to mention that I'm testing the code in Developer-edition new changes arrived there. I will check if other of my code, with the code posted here, makes the issue happens.

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.

Try transform: none !important;

Oh, you're right on the border image, thanks!

As for the other separator, I totally thought it was native, but after reading your comment I started searching in my css files and I found what was causing the green circled issue. Apparently it's this part of the code here:

/* Add somewhat hacky separator to zoom controls so it looks consistent */
#appMenu-protonMainView > .panel-subview-body::after,
#appMenu-mainView > .panel-subview-body::after {
  content: "";
  display: flex;
  border-bottom: 1px solid var(--panel-separator-color);
  margin: var(--panel-separator-margin);
}

which is a part of one of your styles . I'm pretty sure I had this for well over a year since I basically considered it native. When I removed it while keeping the rest, it seems like it's working just fine anyway. Thanks for the help!

Unrelated side question that I don't think it's worth enough to open a thread on different spaces: to test the code I used both Windows 11 and MacOS Tahoe, I noticed that the quit option is missing from the macOS arrowPanel compared to the Windows one. Here's the comparison (mac on the left, w11 on the right) I probably think this is normal as I noticed this in a native, non modded profile (in macOS the about firefox in "Help" section of the arrowPanel is missing as well compared to the Windows one so it wouldn't be strange if quit one is missing as well) but do you happen to know if what I just said is actually right? It's not really important, more like a curiosity lol

Oh, you're right on the border image, thanks!

As for the other separator, I totally thought it was native, but after reading your commented I started searching in my css files and I found what was causing the green circled issue. Apparently it's this part of the code here:

/* Add somewhat hacky separator to zoom controls so it looks consistent */
#appMenu-protonMainView > .panel-subview-body::after,
#appMenu-mainView > .panel-subview-body::after {
  content: "";
  display: flex;
  border-bottom: 1px solid var(--panel-separator-color);
  margin: var(--panel-separator-margin);
}

which is a part of one of your styles . I'm pretty sure I had this for well over a year since I basically considered it native. When I removed it while keeping the rest, it seems like it's working just fine anyway. Thanks for the help!

Unrelated side question that I don't think it's worth enough to open a thread on different spaces: to test the code I used both Windows 11 and MacOS Tahoe, I noticed that the quit option is missing from the macOS arrowPanel compared to the Windows one. Here's the comparison (mac on the left, w11 on the right) I probably think this is normal as I noticed this in a native, non modded profile (in macOS the about firefox in "Help" section of the arrowPanel is missing as well compared to the Windows one so it wouldn't be strange if quit one is missing as well) but do you happen to know if what I just said is actually right? It's not really important, more like a curiosity lol

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?

Perfect, thank you.

.tab-group-label {
        #tabbrowser-tabs[orient="vertical"][expanded] & {
            width: 100% !important;
            text-align: start !important;
        }
    }

Oh, I see. I think that's probably it!

So the only way to have context menus that can be styled with css is disabling widget.macos.native-context-menus, will try this thanks!

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.