Closed Bug 1908200 Opened 2 months ago Closed 2 months ago

Dark theme colors aren't always honored

Categories

(Firefox :: Theme, defect)

Firefox 128
defect

Tracking

()

RESOLVED INVALID

People

(Reporter: littlergirl, Unassigned)

References

Details

Attachments

(9 files)

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0

Steps to reproduce:

Use a dark theme. In my case, I'm using the MagentaNeon theme.

Actual results:

When using a dark theme (any dark theme - not just the one I'm currently using), if no custom CSS is used (when ~/.config/gtk-3.0/gtk.css is renamed or moved, for example), a black background with white text is used for the sidebar, the context menus, and the bookmark manager.

Expected results:

I believe the colors for those Firefox elements used to honor the theme's colors. So, as an example, if your dark theme is hot pink (as mine is), the background of those elements used to be hot pink rather than the black that they are now.

The Bugbug bot thinks this bug should belong to the 'Core::CSS Parsing and Computation' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → CSS Parsing and Computation
Product: Firefox → Core

Thanks for the bug report!

For others' benefit: it looks like https://addons.mozilla.org/en-US/firefox/addon/magenta-neon/ is the relevant theme in the STR here.

Question for you:

I believe the colors for those Firefox elements used to honor the theme's colors. So, as an example, if your dark theme is hot pink (as mine is), the background of those elements used to be hot pink rather than the black that they are now.

How far back are you talking here, RE what Firefox used to do?

I tested Firefox Nightly versions:

  • 2022-01-01 (version 97.0a1)
  • 2023-01-01 (version 110.0a1)
  • 2024-01-01 (version 110.0a1)

...and I'm seeing the same behavior in all of them -- slate-gray background for Ctrl+H history sidebar, for example (despite the hot-pink toolbar color etc).

(I don't have any custom GTK CSS, for what it's worth; my ~/.config/gtk-* directories have no css files in them at all.)

Component: CSS Parsing and Computation → Theme
Product: Core → Firefox

I should mention:

  • I'm on Ubuntu 22.04.
  • I tested with both "Light" and "Dark" as my system-level theme difference (in the Ubuntu settings app) -- I get the same results as described in comment 2 regardless of my choice (white text on slate-gray background for the Ctrl+H History sidebar, when using the MagentaNeon theme).

Also worth noting: the MagentaNeon theme itself shows this on AMO
Last updated 5 years ago (May 13, 2019)
https://addons.mozilla.org/en-US/firefox/addon/magenta-neon/
...so to-the-extent that something changed here[1], it wasn't a change on the theme's side.

[1] (I can't currently reproduce any change having happened, though)

Yep, that's the theme I'm currently using, but note that I mentioned that this happens with any dark theme I've tried, and I've tried many in an effort to establish whether or not it's caused by the theme. I don't believe it is, especially since the theme hasn't changed during all of this, yet the behavior has changed (I can now read text again because the background and font aren't both black any more and now the issue is that the background is always black and the text is always white and I used to have a magenta background).

I'm using Kubuntu 22.04 LTS and the issue first manifested in this release of Kubuntu, but definitely not in this release of Firefox. It was many releases ago.

I seem to have first mentioned it in public (although I'd already been struggling with it privately before that) in September of 2023 in the "Theme issue with Firefox Snap update to revision 3068" thread on 2023-09-03 in the ubuntu-users mailing list. Here's the thread: https://lists.ubuntu.com/archives/ubuntu-users/2023-September/311092.html

If you follow that thread, it eventually resulted in my filing this bug report on Launchpad: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2033988

And that report ended in a suggestion for me to file a report here, so here I am.

I do have all kinds of rules in my ~/.config/gtk-3.0/gtk.css file, but I renamed it so it wouldn't be used in order to test whether the problem described in the Launchpad bug above had been solved and that's when I discovered that the original issue had been solved, but this one exists.

I'm attaching several screenshots for you. All but one were taken with the MagentaNeon theme in place. I also took one with a light theme in place so you can see what that looks like.

The screenshots show the dark theme with the history open in the sidebar, the bookmarks open in the sidebar, the bookmark manager open, and the magenta bookmarks toolbar with a folder open to show its context menu.

I followed that by switching to the CMYK-Pastel light theme and once again opening a folder on the bookmarks toolbar to show that its background is yellow (as are the backgrounds of the history, bookmarks, and bookmark manager, but I figured one screenshot was enough to give you the idea). If I use the default light theme that comes with Firefox, the background of all of those is white.

I messed around with a few of my light themes and some of them use the theme's light background color while others use the black (or as you call it, slate-gray) background color. That makes me wonder whether that slate-gray isn't somehow a default that occasionally gets used for reasons as-yet-unknown to me (or whether dark is specified rather than light somewhere where it shouldn't be), although that might not explain why the MagentaNeon theme used to have a magenta background and now has a slate-gray one, which points to some sort of change in Firefox.

Anyway, thanks for your active interest and good luck with this. Feel free to let me know if you'd like any further information or screenshots.

Attached image HistorySidebar.png
Attached image Bookmarks.png
Attached image BookmarkManager.png

I decided to add a screenshot of the bookmarks toolbar context menu while using the default light theme that comes with Firefox, just for the sake of completeness.

Last, but not least, I figured I'd mention that I keep my system updated and the Firefox Snap updates itself as needed.

Thanks for all that info!

So, if I'm understanding correctly:

  • As of the Firefox 117 snap, with certain dark themes and gtk.css customizations, you ended up with dark text on a dark background in various sidebars.
  • However, nowadays you're seeing light text on a dark background in those sidebars (so the text is readable once again).
  • But you recall the Firefox-theme-colors being used instead for that sidebar UI at some point in the past, hence this bug here being filed.

I'm glad the black-text-on-black-background issue is resolved. :) As a shot-in-the-dark, maybe that was caused in some way by bug 1838460 (which was a gtk theming change that shipped in Firefox 117)? In any case, though, probably not worth worrying about too much at this point now that it's fixed.

Regarding your recalled "better" behavior with theme-controlled background colors for the sidebar etc: it's hard to chase that thread without knowing what build was "good" or being able to reproduce that behavior (per my spot testing of a handful of old versions in comment 2). If you're sure about that and you're interested to poke, perhaps you might be able to pinpoint a "good" Nightly version using mozregression? (installable as pipx install mozregression if you have pipx, and then launchable as mozregression --launch 2023-01-01 for example to launch that Nightly build with a disposable Firefox profile)

For what it's worth, I used devtools to inspect a modern Firefox Nightly window to see how the sidebar background is defined -- it's here:
https://searchfox.org/mozilla-central/rev/a95ca2357da6bccc6c5b12f662dd8a4e5bcbf892/browser/themes/shared/sidebar.css#7-8,13-14

:root {
  --sidebar-background-color: -moz-sidebar;
...
#sidebar-box {
  background-color: var(--sidebar-background-color);

...where -moz-sidebar is a system color keyword whose value comes from this mSidebar assignment on Linux, I think -- coming directly from the GTK theme:
https://searchfox.org/mozilla-central/rev/a95ca2357da6bccc6c5b12f662dd8a4e5bcbf892/widget/gtk/nsLookAndFeel.cpp#2088-2093
...though also you can override it by creating an about:config pref ui.-moz-sidebar and setting that to e.g. the string rgb(0,255,0) for lime or rgb(255,0,255) for hot pink.

I wonder if your good-ol'-days recollection is from a time where you either had a GTK theme (or gtk.css) that provided colors that just-so-happened to match your Firefox theme (and Firefox was picking up on those GTK theme colors as noted above, not the Firefox theme colors)? Or perhaps you had set ui.-moz-sidebar etc. to colors that matched your preferences, and your customizations to those prefs have since been lost?

In any case: these days I think the correct way to adjust this is to use one of those methods -- adjusting either your GTK theme or your Firefox preferences to set your preferred foreground/background colors.

emilio might know if there's some further nuance here, too. But in the absence of an identified "good" old Firefox version, I'm suspicious that the recalled good behavior was in fact coming from the GTK theme settings (which Firefox uses) or from about:config settings.

See Also: → 1838460

So, tl;dr: I think there's a reasonably good chance that your ~/.config/gtk-3.0/gtk.css file (and/or an about:config pref like ui.-moz-sidebar) was in fact the thing that was providing the colors for this sidebar; it was probably not your Firefox theme, though it's not surprising that someone (e.g. past-you) might set those theming constants up to look nice together and then forgotten which part was responsible for coloring which bits of the UI.

Having said that, if you can find an old Firefox version that respects the Firefox theme colors for this sidebar instead, then I'm happy to be wrong and that would be interesting, and it would present an actionable rabbit-hole that we could go down to bisect builds to see if we can find out when/why that changed!

I was reading through these again and noticed that in comment 3, you mentioned testing with both "Light" and "Dark" as your system-level theme difference (in the Ubuntu settings app). I realized that I don't know what that means. We don't have that in Kubuntu and the light and dark themes I've been talking about here are Firefox themes that have nothing to do with Kubuntu.

In the event that it has some significance here, my Kubuntu settings, I'm offered three choices for GTK application style: Breeze, Default, and Emacs. I use Breeze. Changing those didn't help with the circumstances of this bug report or the Launchpad one mentioned above.

Also in comment 3, you mentioned that you get the same results as described in comment 2 regardless of your choice of theme. Did that mean that you always see a slate-gray background and white text even when you're using a light Firefox theme? If not, then I misunderstood it. If so, then that's not the behavior I get. The light themes definitely change how the sidebar contents look.

And yes, your understanding is right, other than that I'd specify that it was version 117.0 in which the original issue occurred (black [slate-gray?] text on a black [slate-gray?] background) and it remained that way through the remaining 117 point-releases and beyond, but as you saw, has now been fixed (yay - good riddance to invisible text).

I tried the modified version of the CSS you suggested (as seen below) and adding them to my gtk.css file does nothing:

:root {
  --sidebar-background-color: #FF00FF;

#sidebar-box {
  background-color: #FF00FF;

I don't have pipx installed, but can install it in a VM. So, since I know I saw good behavior in Kubuntu 22.04 LTS at some point, I'm assuming that the furthest back I need to go is 2022-04-21 since that's its birthday.

Now to check whether I have the steps right:
1. Install pipx from the Ubuntu repository.
2. Use this command to install mozregression: pipx install mozregression
3. Use this command to launch the nightly build of Firefox with a disposable Firefox profile for the specified date: mozregression --launch 2022-04-21
4. Check for the presence (or lack thereof) of the issue.
5. Repeat steps 3 and 4 for each date that you'd like to test.

We're making some headway with your temporary fix. I tried the about:config recommendation. Note that #FF00FF works just as well as rgb(255,0,255) as the string, so that's what I'm using. Anyway, that's making a nice difference in how the sidebar looks, although it still needs some work.

I'm attaching three images showing what it looks like to have the bookmarks open in the sidebar when using the default light theme, the CMYK light theme, and the MagentaNeon dark theme. Of the three, the MagentaNeon theme seems to be responding the best, because it's the only one that uses white text. Note, too, that that theme has a black (slate-gray?) border or divider between the sidebar and the main window, unlike the other two, which is interesting.

I wasn't able to figure out how to use the CSS you gave me. You wouldn't happen to have a list of all default CSS selectors for Firefox, would you? Then I could just plop one or more of them into the gtk.css file to deal with any style issues that ever arise.

Likewise, if you happen to have a list of all the default CSS variables that can be used inside of about:config, I wouldn't mind having to use that method to style Firefox in the event that I need to override some default styling.

Depends on: 1886847
Flags: needinfo?(sfoster)

You may be right that my ~/.config/gtk-3.0/gtk.css file was providing the colors for the sidebar, but it's also possible that something changed at Firefox's end to make my CSS selectors stop working the way they had been.

I've been tinkering inside of the ~/.config/gtk-3.0/gtk.css file on and off for quite some time and have occasionally had to make adjustments when a new selector was added that happened to affect existing selectors. However, I've always been aware of that immediately and counteracted it immediately, and I've always left myself with CSS that was working in all of my GTK programs after any change. If something didn't work, I filed a bug report.

I'll try your suggestion to use the mozregression tool in a VM to try to find a working release and I'm glad to hear you won't mind rummaging around inside the potential rabbit-hole that may present itself as a result of this experimentation. Meanwhile, thank you so much for adding just a bit more pink to my Firefox.

The right fix is making the MagentaNeon theme author specify stuff like sidebar_text and sidebar_background colors TBH....

(In reply to Emilio Cobos Álvarez (:emilio) from comment #26)

The right fix is making the MagentaNeon theme author specify stuff like sidebar_text and sidebar_background colors TBH....

Ah, right. So probably, the reporter used to use a theme that specified those colors (which is the "good" state that they're remembering), and other themes like MagentaNeon happen to not-specify these colors.

Here's one theme that does seem to set that sidebar background-color (to a dark blue color), as an example of this working properly, given a theme that sets the appropriate values:
https://addons.mozilla.org/en-US/firefox/addon/spirited-away-animated/

@littlergirl: if that^ theme successfully sets the sidebar color for you (as it does for me), then I think we're all good here and this is just a case where you picked a theme that happens to not-specify a color for that bit of UI. :)

(In reply to littlergirl from comment #18)

I tried the modified version of the CSS you suggested (as seen below) and adding them to my gtk.css file does nothing:

Sorry, the CSS that I had quoted there wasn't meant as a suggested-edit for you to do -- that was just me quoting the CSS that Firefox uses internally to style this component, as a reference. I have no idea offhand what the correct gtk.css styles would be that you could use to influence these colors (just due to my own ignorance of gtk.css internals); but you can try visiting about:config and creating a string-valued preference called ui.-moz-sidebar with value e.g. rgb(255,0,255) to manually make the sidebar pink. ui.-moz-sidebartext will influence the color of some of the text there. The list of full about:config prefs to play with (if you like) is at https://searchfox.org/mozilla-central/rev/8c6edfe25c094e032a27722ef30f69555f556bf8/widget/nsXPLookAndFeel.cpp#215 , and you can see which (if any) of those is being used for a particular piece of the UI by using the Browser Toolbox ( https://firefox-source-docs.mozilla.org/devtools-user/browser_toolbox/index.html ) to inspect the Firefox UI and drill down to find the relevant CSS keyword.

Possibly better, though, would be to build your own theme with Firefox Color: https://color.firefox.com/

That theme does successfully set the colors for the sidebar, etc. It looks like you two have got it sorted out. The issue is with the themes and would need to be solved by their authors.

Thank you for the list of about:config prefs. I'm keeping that just in case it's ever needed, because that was a quick, easy, temporary "fix" and could be again in the future.

Thank you, also for the Browser Toolbox recommendation, but since remote access to my machine has to be enabled to use it, that's not something I would use.

Firefox Color is stunning. I'll be creating my own theme. Thank you so much. That right there is perfect.

I'm resolving this as invalid since it's not anything your team needs to fix. I hope that's okay. If not, please feel free to change it.

Status: UNCONFIRMED → RESOLVED
Closed: 2 months ago
Resolution: --- → INVALID

(In reply to littlergirl from comment #28)

Thank you, also for the Browser Toolbox recommendation, but since remote access to my machine has to be enabled to use it, that's not something I would use.

Reasonable to be concerned, yeah -- fortunately it's actually not that much of a security foot-gun -- the UI there is misleading. "Remote" there really means "other programs on your machine" (e.g. the Browser Toolbox itself which runs as an separate external process). There's an additional about:config pref that would have to be turned off in order for actually "remote" connections to be accepted from the network. I chatted with the DevTools team to confirm this and they agree that the documentation should be clarified to make it clearer what "remote" actually means for this checkbox. But in any case, it sounds like you don't need to use Browser Toolbox for your use-case after all.

Firefox Color is stunning. I'll be creating my own theme. Thank you so much. That right there is perfect.

Hooray! I'm glad it helps.

(In reply to littlergirl from comment #29)

I'm resolving this as invalid since it's not anything your team needs to fix. I hope that's okay. If not, please feel free to change it.

Thanks!

Flags: needinfo?(sfoster)

That's good news about Browser Toolbox. Updating the documentation sounds like a great idea. They'll also want to consider changing the label for that option in the UI. I've made a note in my personal wiki that the Browser Toolbox is safe to use in case it's ever needed.

By the way, although this bug report ended up being invalid, I'm really glad that the suggestion was made to submit it. You've managed to teach me a lot in a very short amount of time and it's much appreciated.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: