Sad to hear that, each day less user power for Firefox, Thanks for the answer.
comments
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.
That's exactly what I needed. So, the problem is solved. Once again, thank you so much for your help!
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).
Thanks for this great idea! I was thinking of changing the padding-block on .text-container instead, but it’s obviously the same principle.
Your code might work... but the problem is that if padding-block isn’t defined in certain contexts, or if it’s set to a different value, then it automatically defaults to 3px. For example, in the moz-message-bar.css file, we can find:
.text-container {
padding-block: calc((var(--message-bar-container-min-height) - 1lh) / 2);
}
Is it possible to specify something like this instead:
div.text-container { padding-block: var(--uc-container-block-padding, initial) !important }
Or even simply:
div.text-container { padding-block: var(--uc-container-block-padding) !important }
In that case, will the value of padding-block (when --uc-container-block-padding is not defined) be its initial value? Or will it be reset to 0px?
Thank you very much for your help and advice!
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.
That has nothing to do with this post, which is about the Firefox interface.
Many site seem to be taking up tall, nearly blank bars across the top of their pages. (Which they are happy to make hard to filter with one or two or even 3 uBlock filters.)
They don't seem to realize that some of us need to zoom pages to make them more readable ... and that zoom makes the bar sizes grow as well ...
For example:
:host(.infobar) {
.container { padding-block: 0 !important; }
}
does nothing. Deleting :host(.infobar) { would work, but obviously that would impact all the containers and is not desirable.
Make sure your selectors have higher priority
That's a very clear and detailed explanation. I had skimmed through a few pages about the flex property, but I didn't really understand much of it. Thank you for taking the time to explain all this to me! It makes a lot more sense to me now.
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.
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 }
I don't quite understand. The CSS for the Library seems more complex (to a novice like me) than that of other parts of Firefox. Is the "flex" property a multiplier? Adding "flex: 1.4" is enough to get what I want... so why should I choose a large number like 1000?
which is only really possible by building Firefox yourself or injecting the style using autoconfig feature.
I've used an autoconfig before... but in this particular case, it's really not worth the trouble for such a small thing. Still, thank you very much for your explanations, which always help me understand a little better how all this works.
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.
Thank you very much! It seems to be working perfectly.
If I may ask, I'd have two more requests:
-
In the Library, is it possible to reduce the space between the toolbar (
#placesToolbar) and the search fields ("Search History", "Search Downloads", or "Search Bookmarks")? Actually, since I wanted to add a margin to the left of#placesToolbar(#placesToolbar { margin-left: 16px; }), the width of the search fields becomes very narrow when the Library window isn’t maximized... -
I removed the border from most tooltips to match those in my GTK+ theme:
tooltip { border: 0 !important; }. However, the Library’s tooltips still have a border. Is it possible to remove it?
Thanks again for your help!
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;
}
that worked tremendously! thanks!
I'll give it a shot when I get back to my computer!
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;
}
Sadly it doesn’t seem to work in my case (?)
I solved adding the next code in userChrome.css, instead of using userContent.css, or maybe is neccessary to use both codes in each file:
:root:is([privatebrowsingmode="temporary"]) {
--tabpanel-background-color: transparent !important;
}
I use the Firefox Color extension. Allows you to change the hex color value of almost every part of Firefox.
the button will stay hidden until you open the panel once - which is a bit tricky since the button is hidden
It's tricky... but it's still doable, since you can always click on the first 8 pixels of the address bar to make the button appear. So I think your solution is excellent! Thank you so much!
the value is set to var(--space-small) so you could possibly just modify that
Yes, that's perfect! Thank you so much for your help!
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;
}
Thanks, it worked! I had no idea of the change