So, the bug that caused this is bug 2058134. The change that was made there is rather inconvenient for user styling, because now the text painting code simply looks if author styles (e.g the web page author) change the selection color and only then use the css specified colors. I'm pretty sure that means that ::selection does absolutely nothing when used in user{Chrome/Content}.css files because they are user, not author styles.
If you want this changed then you should create a new bug and mark it as being regressed by the above bug.
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:
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.
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:
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:
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.
These new profiles that can be accessed through menu are not exactly sub-profiles, but I think more like sibling-profiles forming a profile group. Profiles in the same group know about each other, so in the UI you can switch between them and I think there are some settings that can be shared between the profiles in the same group.
I don't know of any plans to deprecate the old profile system, nor about:profiles for managing them.
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.
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.
I would seriously suggest to at least check the last modified time of the file instead of constantly re-computing all the style rules every second. So at the very least:
// store last known modified time
var previousModified = 0;
setInterval(() => {
// ...
chromepath.append("userChrome.css");
// check last modified time before proceeding
var modified = chromepath.lastModifiedTime;
if(modified <= previousModified){ return }
previousModified = modified;
var chromefile = io.newFileURI(chromepath);
// ...
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):
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.
I believe this is basically the same issue as this one for why scrollable menupopups style stopped working in fx 155. I managed to get my style working again, but with a limitation that the popup list can't be scrolled with keyboard anymore.
So, the bug that caused this is bug 2058134. The change that was made there is rather inconvenient for user styling, because now the text painting code simply looks if author styles (e.g the web page author) change the selection color and only then use the css specified colors. I'm pretty sure that means that
::selectiondoes absolutely nothing when used in user{Chrome/Content}.css files because they are user, not author styles.If you want this changed then you should create a new bug and mark it as being regressed by the above bug.
Sure, if padding-block isn't set then
initialshould be alright. I'm guessing the initial value would be0pxso 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 isrevert-rule. Whereasinitialmakes the property use it's "browser default" value, usingrevert-ruleas a fallback makes it use whatever it would have been without that custom style rule - so it would in this case revert tocalc((var(--message-bar-container-min-height) - 1lh) / 2).Similar to
::part, the:hostselector 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:This is a bit unfortunate complication, that could in theory break a bit if eg.
eg.containerelements 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
1then 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.I think what you want to do for the Library toolbar is to make the search input box flex more that the spacer space:
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:
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:The tab scrollbar you can probably make bigger simply like this:
I don't think that's possible. At least, not exactly how you you described it. You could get pretty close like this:
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
!importantyour userChrome probably won't override it. But luckily the value is set tovar(--space-small)so you could possibly just modify that. Something like this:Add
!importanttag to the fill property - menu.css in Firefox 149 specifies a fill property for those elements so you now need to override that.SelectedItemis just a normal(*) keyword value for color likewhite,black,redetc. 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.selecteditemand set it to#ff0000and it should become red.This seems to be a recent regression in nightly - I created bug 2011219 for this.
These new profiles that can be accessed through menu are not exactly sub-profiles, but I think more like sibling-profiles forming a profile group. Profiles in the same group know about each other, so in the UI you can switch between them and I think there are some settings that can be shared between the profiles in the same group.
I don't know of any plans to deprecate the old profile system, nor about:profiles for managing them.
If you are using
@importstatements 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:
Or if you want tabs to be below that fake statusbar then add this as well:
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/profilethus 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.I would seriously suggest to at least check the last modified time of the file instead of constantly re-computing all the style rules every second. So at the very least:
Sure, you can apply reloading like that if you want. But I would be careful when using that as
.uc.mjsbecause 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
@importstatements 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):
Adding that as
<filename>.sys.mjsshould 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.