bug: Wrong colors used in firefox gnome plugin & GTK 3 theme

[ZechariahB]

Is there an existing issue for this?

• [X] I have searched the existing issues

What happened?

Since it is the weekend, I found you guys something interesting.

Border colors are set to a wrong color for Firefox GNOME Theme in customChrome.css, leading to bright borders on a dark theme. The culprit is --gnome-inactive-toolbar-border-color read from @headerbar_border_color. Why do all presets set @headerbar_border_color to a bright color for a dark theme? Is that supposed to be a bright color? Anyways, removing line 23 of firefox_gnome_theme.py "fixes" this: --gnome-inactive-toolbar-border-color: {headerbar_border_color};

Border colors are then broken for light theme presets? They seem like they are not supposed to look this dark compared to actual Gtk 4 apps. More colors surely need to be defined for light themes to work properly. I suggest also defining variables for private windows as they are currently difficult to read using a light preset.

Additionally when you use a light theme preset and use a right click menu in a GTK 3 app like Nautilus, hovered elements have incorrect unreadable colors. I tried multiple presets and this always seems to happen. The result is in these screenshots below.

To Reproduce

• Use latest firefox gnome theme plugin. Do not use 0.3.1 release version.
• Generate a color scheme from Monet or use any presets you want
• Apply the color preset with firefox gnome theme plugin enabled

Expected behavior

Firefox Gnome Theme plugin should be set to have color parity. Menus should also be easier to use.

Screenshots

Wrong colors (captured from Firefox) -> Gruvbox Light Intended colors (captured from Nautilus) Firefox private window with a light preset Right click menu using Nautilus with a light preset -> Cobalt Light

Version

0.3.1

Installation method

Flatpak from Flathub

Code of Conduct

• [x] I agree to follow this project's Code of Conduct

[GradienceBot]

Welcome on Gradience. 🥳 We really appreciate your contribution. The core team will review your issue as soon as possible. You can also join the matrix room https://matrix.to/#/#Gradience-space:envs.net or the discord server https://discord.com/invite/4njFDtfGEZ

[0xMRTT]

Thanks for reporting. That'll be fixed in the next release

[daudix]

@ZechariahB Is this issue fixed for you in 0.3.2?

[ZechariahB]

Sorry for the delay. My college semester is ending with a whole lot of work. Currently, this issue is not fixed fully.

Nautilus has been upgraded to GTK 4, so I suppose Nemo would be a good alternative. The context menu with light presets works. Wrong colors for the firefox theme is currently not fixed.

I rambled on without being descriptive enough. Apologies to anyone waiting on for this issue. The awkward colors featured in first screenshot are reproducible from enabling 'prefer-dark' in dconf at /org/gnome/desktop/interface/color-scheme. Firefox GNOME Theme mixes in colors not themed by the plugin, which is not good. Any colors you not define default to either light.css or dark.css (default color theme) within Firefox Gnome Theme. Borders are affected as well.

Many variables are still not defined by the plugin. (You have --gnome-inactive-toolbar-border-color but no --gnome-toolbar-border-color for example). Private window colors are sectioned off in another :root selector in Firefox GNOME Theme. Private window colors absolutely must be defined in customChrome or else their colors will be wrong. You can copy everything in light.css except for private window colors and paste them in customChrome.css. Third screenshot shows that signature look no matter if using 'prefer-dark' or 'prefer-light'.

The template used in the plugin is definitely bad. The issue was improved significantly after defining more colors. Private window was fixed and readable. I think it is necessary to define most, if not all colors to avoid theme related issues. Here is light.css and dark.css taken from latest Firefox GNOME Theme update. light.css can be a template.

Cssfiles.tar.gz