Some form fields are black on Gtk3 dark themes

NEW
Unassigned

Status

()

P3
normal
3 years ago
a month ago

People

(Reporter: dxzlabs, Unassigned)

Tracking

(Depends on: 1 bug, Blocks: 1 bug)

49 Branch
Unspecified
Linux
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: tpi:+, URL)

Attachments

(3 attachments)

(Reporter)

Description

3 years ago
Posted image firefox.png
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:49.0) Gecko/20100101 Firefox/49.0
Build ID: 20160629004019

Steps to reproduce:

1) Apply dark theme, Arc Dark, Vertex, etc.
2) Open https://addons.mozilla.org/en-US/firefox/users/login in firefox



Actual results:

See input is black: http://i.imgur.com/CzBtVHD.png


Expected results:

In chromium this is ok: http://i.imgur.com/RYq95mh.png
(Reporter)

Updated

3 years ago
OS: Unspecified → Linux
(Reporter)

Comment 1

3 years ago
Posted image chromium.png
(Reporter)

Comment 2

3 years ago
System info:
GTK Theme: Arc-Dark [GTK2/3]
System:    Host: pc Kernel: 4.6.3-1-MANJARO x86_64 (64 bit) Desktop: N/A
           Distro: Manjaro 16.06.1 Daniella
Machine:   System: LENOVO (portable) product: Lenovo IdeaPad Y580 v: Lenovo IdeaPad Y580
CPU:       Quad core Intel Core i7-3610QM (-HT-MCP-) cache: 6144 KB 
Graphics:  Card-1: Intel 3rd Gen Core processor Graphics Controller
           Card-2: NVIDIA GK107M [GeForce GTX 660M]
           Display Server: X.Org 1.17.4 driver: intel Resolution: 1920x1080@59.93hz
           GLX Renderer: Mesa DRI Intel Ivybridge Mobile GLX Version: 3.0 Mesa 11.2.2

Comment 3

3 years ago
is it the only website with form affected?
(Reporter)

Comment 4

3 years ago
(In reply to Loic from comment #3)
> is it the only website with form affected?

No, many sites, for example youtube.com:
http://i.imgur.com/j65NdQU.png

https://manjaro.ru/login/
http://i.imgur.com/gPCO1uH.png

With white system themes(lxappearens to change theme) no problems.

Comment 6

3 years ago
/*
text widgets and the like base background color */
@define-color theme_base_color #232629;

or

/*
text widgets and the like base background color on backdrop windows */
@define-color theme_unfocused_base_color #232629;

Updated

3 years ago
Blocks: 627699
Component: Untriaged → Widget: Gtk
Product: Firefox → Core
Summary: https://addons.mozilla.org/en-US/firefox/users/login input is black on dark themes → Some form fields are black on Gtk3 dark themes
Version: unspecified → 49 Branch
Priority: -- → P3
See Also: → bug 1158076
Whiteboard: tpi:+
A partial fix (for Firefox 55 and e10s enabled) is to add new string key to about:config with "widget.content.gtk-theme-override" name and "Adwaita:light" value.
The problem here is that the Arc Dark theme is dark by default and does not have light/dark variant.

Comment 9

a year ago
There does seem to be a light variant of the Arc theme now, in Fedora 26 Cinnamon at least.

Comment 11

a year ago
(In reply to Martin Stránský [:stransky] from comment #7)
> A partial fix (for Firefox 55 and e10s enabled) is to add new string key to
> about:config with "widget.content.gtk-theme-override" name and
> "Adwaita:light" value.

I can confirm this partial fix works just fine on FF 57 running Fedora 27 / KDE.

Thanks.

Comment 12

a year ago
The fact that Firefox cannot handle dark desktop themes was reported many times FOR SEVENTEEN YEARS.

Seventeen years. And still an issue.

Webpages display partly in system colors causing white on white or black on black text/form elements, while parts of the Firefox UI defy every dark theme and stay eye-bruning white.

I hoped that finally Quantum will fix this... but it MADE IT WORSE!

Now several parts of the FF GUI have white on white checkboxes or disabled text, and everything in settings is blazing white as well as new tab page.


All you need to do to fix the websites is to use the widespread defaults instead of system colors to render webpages.

color:black;
background-color:white;

DONE.

But you can't do this for 17 years for reasons beyond comprehension.

WORKS in Chrome (USES GTK TOO!)
WORKS in Internet Explorer
WORKS in Microsoft Edge
WORKS in pretty much EVERYTHING other than Firefox.


Just a few tickets about problems with dark themes, in order:

https://bugzilla.mozilla.org/show_bug.cgi?id=70315 <--- 17 years old report!!! Still "New"!
https://bugzilla.mozilla.org/show_bug.cgi?id=1195138
https://bugzilla.mozilla.org/show_bug.cgi?id=1268338
https://bugzilla.mozilla.org/show_bug.cgi?id=1283086
https://bugzilla.mozilla.org/show_bug.cgi?id=1379725
https://bugzilla.mozilla.org/show_bug.cgi?id=1385518
https://bugzilla.mozilla.org/show_bug.cgi?id=1391007
https://bugzilla.mozilla.org/show_bug.cgi?id=1393927
https://bugzilla.mozilla.org/show_bug.cgi?id=1402312
https://bugzilla.mozilla.org/show_bug.cgi?id=1408121
https://bugzilla.mozilla.org/show_bug.cgi?id=1414693
https://bugzilla.mozilla.org/show_bug.cgi?id=1415511
https://bugzilla.mozilla.org/show_bug.cgi?id=1418090
https://bugzilla.mozilla.org/show_bug.cgi?id=1424422
https://bugzilla.mozilla.org/show_bug.cgi?id=1425161
https://bugzilla.mozilla.org/show_bug.cgi?id=1425517
I think it a big unfair to say that Firefox does not support that at all. When you get stock browser with default settings it behaves (or should behave) the same as Chrome/Chromium (I can't say about Windows browsers). Dark themes are disabled by default and all UI/Web elements are shown as black on white. The issue is that some dark Gtk themes are not properly marked as dark (like Arc on KDE). How can we detect them then?

The problem is that Firefox honor your desktop theme which causes the issue. Chrome/Chromium do not care about your desktop theme and uses stock browser theme.

You can easily emulate what Chrome/Chromium does by running "$GTK_THEME=Adwaita:light firefox" - to set default Gtk+ theme just for Firefox.

I'll also investigate if it's possible to set the different UI theme by Firefox pref (we have a pref for content only - widget.content.gtk-theme-override.
(In reply to Martin Stránský [:stransky] from comment #13)
> I think it a big unfair to say that Firefox does not support that at all.

Err, sorry, I mean a *bit* unfair here :)
> The problem is that Firefox honor your desktop theme which causes the issue.
> Chrome/Chromium do not care about your desktop theme and uses stock browser
> theme.

I just checked the chromium-browser and Arc-Dark theme and looks like it honors dark colors for UI only which is what we also want for Firefox.

Comment 16

a year ago
To my knowledge Firefox is the only browser that lets system colors bleed into webpages.

Testing on Chrome (both Linux and Windows) and MS Edge showed that they both have sane default fallbacks (=black text and white BG) even when there is a dark system theme.

Firefox is affected on both Linux and Windows apparently.

Comment 19

a year ago
(In reply to Martin Stránský [:stransky] (Back on Feb 12) from comment #7)
> A partial fix (for Firefox 55 and e10s enabled) is to add new string key to
> about:config with "widget.content.gtk-theme-override" name and
> "Adwaita:light" value.

It worked like a charm!! Thank you so much. 
I'd been using a workaround which needed the file "userContent.css" to be modified. But the solution you gave is way better. Thank you, again.

Comment 20

a year ago
"widget.content.gtk-theme-override" saved me as well. Thanks a lot.

Comment 21

a year ago
Seventeen years.

Getting worst...
Thanks everyone for the workaround, it's helping a lot.
I have the same problem on my Linux Mint Mint-Y-Dark theme.

Comment 22

a year ago
(In reply to quentin.danjou from comment #21)
> Seventeen years.
> 
> Getting worst...
> Thanks everyone for the workaround, it's helping a lot.
> I have the same problem on my Linux Mint Mint-Y-Dark theme.

btw I didn't find any "widget.content.gtk-theme-override" field in my about:config (58.0.2 (64-bit))
You need to add "widget.content.gtk-theme-override" by hand, click by right mouse button there and add as "string" value "Adwaita:light".

Comment 24

a year ago
17 years open issue.. I remember that some years ago I added a css file to my profile directory for a css reset. The workaround with gtk-theme-override is maybe more elegant but still not a solution.

I don't know anything about who is making decisions for firefox. But the decision that the gtk color should be used as default is stupid. Of course you could say every website maintainer with these issues: "please change also the background color when you change the text color". Microsoft did something similar when they released IE8 (?) - all just laughed about it.

In my opinion it should be a definition from W3C: by default an input field has white background and dark text. If a browser than makes it different it's not W3C conform and a lot of people will understand why to use another browser.

Comment 25

a year ago
I just realized that this is also not working for options from a select box. At the end I came to the conclusion that even when firefox needs less memory and has a nicer gtk look I'm still more happy with the rendering of webpages in chrome...

Comment 26

10 months ago
The "widget.content.gtk-theme-override" config worked for me too, I'm using xubuntu 18.04

Comment 27

9 months ago
Chrome/Chromium has an option to use GTK theme or not. It's disabled by default, but it doesn't bleed into HTML page, just the chrome window itself. May be just adding a flag like that may help to remove any problem in decision. But I understand that HTML widgets should follow the W3C specification, not the user theme. Of course that allowing this by using a opt-in flag is a solution, but I don't see anyone wanting this very specific behaviour.

Some screenshots comparing it (Fedora 28, KDE, using Breeze-Dark theme for KDE and GTK (Through a port)).

http://i.imgur.com/aWFcqFy.png
http://i.imgur.com/upJzQD8.png
http://i.imgur.com/UiOgOlz.png
http://i.imgur.com/jrHk8GK.png

Comment 28

8 months ago
Unfortunately because a lot of web developers expect browsers to have default style that don't change based on your system styles it is not OK the have your system styles change expected browser defaults.

Developers would have to expect system styles and be able to disable them if they so consider necessary for their viewing experience.

Bottom line is having GTK styles in a web page should at best be a experimental feature and not enabled by default.

The firefox UI is fine but the web page content should be off limits given the verity of ways people build sites now.

Comment 29

8 months ago
(In reply to Martin Stránský [:stransky] from comment #7)
> A partial fix (for Firefox 55 and e10s enabled) is to add new string key to
> about:config with "widget.content.gtk-theme-override" name and
> "Adwaita:light" value.

I am very grateful to you!

Comment 30

6 months ago
This fix works.  Is there a reason this is still "Unconfirmed"?

I think native styling is a great idea, but should be opt-in *by the website developer*.  It seems the best method to integrate with a website is to make the theme available to the website.

An alternative would be to detect low-contrast combinations that "shouldn't" exist, such as "a text + os theme color produce a low-contrast combination", and modify them.  Note, for things like spoilers, you wouldn't want to kill *all* low-contrast developer decisions, just those that are from combination with theme background.  But, that seems like a lot of work, and is ultimately *more* meddling with web developers' decisions, not less.

Comment 31

6 months ago
Edit:  By the way, I think it's *great* that Firefox honors GTK themes -- however, this should be limited to the UI, or shouldn't affect the page unless the page opts-in somehow.

Comment 32

5 months ago
How is it possible that this bug is still UNCONFIRMED?
It is very much confirmed and if the developers excuse is that they just use the default theme is not a valid excuse to ignore other use cases.
People regularly use the hack of adding "widget.content.gtk-theme-override" which makes them shut up about it, preventing to complain here, so this feels less important.
I'm almost sorry that this "fix" exists.
(In reply to Marko from comment #32)
> How is it possible that this bug is still UNCONFIRMED?
> It is very much confirmed and if the developers excuse is that they just use
> the default theme is not a valid excuse to ignore other use cases.
> People regularly use the hack of adding "widget.content.gtk-theme-override"
> which makes them shut up about it, preventing to complain here, so this
> feels less important.
> I'm almost sorry that this "fix" exists.

The proper fix for that is to disable themes for the web content and provide a modern theme for it. But this is rather long therm project.

A quick fix I can imagine for that is to detect the dark theme somehow (that's the tricky part) and then set widget.content.gtk-theme-override to Adwaita:light because it's always present as a default Gtk+ theme. I imagine such workaround should be under preference and disabled by default, also disabled when widget.content.gtk-theme-override is set by user.

We can't use Adwaita:light as a default content theme for all as it does not fit well with other themes like Breeze on KDE or Ambiance; Adwaita has large buttons/entries/comboboxes. But maybe we can decrease the widgets size when we're painting HTML content in such "fallback" mode.

Karl, what do you think about this idea?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(karlt)
QA Contact: jmathies
(In reply to Martin Stránský [:stransky] from comment #33)
> A quick fix I can imagine for that is to detect the dark theme somehow
> (that's the tricky part) and then set widget.content.gtk-theme-override to
> Adwaita:light because it's always present as a default Gtk+ theme. I imagine
> such workaround should be under preference and disabled by default, also
> disabled when widget.content.gtk-theme-override is set by user.

This is along the lines of discussion in bug 1461538.

The goal with configurable options is to pick a default which is the one which
/most/ people would prefer or works best /most/ of the time.  I don't
have a good feel for whether substituting Adwaita:light or sticking with the
user's explicitly chosen theme is the better option.

If you think that Adwaita:light would be the preferred default for that
situation, then it sounds sensible to implement better heuristics for dark
theme detection.  Even if such heuristics turn out to not be perfect, they can
still work well most of the time.

I wouldn't go to the trouble of implementing this if the intention is that it
should be off by default (but turned on by another new pref).

The widget.content.gtk-theme-override pref could be made more discoverable by
adding it to modules/libpref/init/all.js.

> Adwaita has large
> buttons/entries/comboboxes. But maybe we can decrease the widgets size when
> we're painting HTML content in such "fallback" mode.

I expect this part would be awkward and risk unexpected consequences.
We had problems with text being cut off when the buttons or entries were
smaller.  I wouldn't make these smaller just for the sake of making them
smaller.  ISTR there were peculiarities in the way padding was managed, which
could be improved to let a document specify smaller padding, or have smaller
padding by default, or not add both document and theme padding, or something
similar (don't recall details).

I also think this is unnecessary.  There will be significant other differences
in the colors of the themes, for example, and so I don't see a lot of value in
trying to make the button sizes more compatible.  Before too long
distributions will have new and different default theme, and such tweaking may
seem inappropriate.
Depends on: 1411425
Flags: needinfo?(karlt)
See Also: → bug 1461538
In this bug report, the text boxes are not even rendered with native borders,
and so it seems unnecessary to use the native background colors for such
elements.  The core problem may be using native colors when the widgets
are not native.  While an algorithm to choose different colors in these
situations seems feasible and I'd like that solution if practical, I guess
that may not fit in well with the way the CSS style system is currently used.
I guess such a solution would require something like making -moz-FieldText
render black when ThemeSupportsWidget() returns false, and change "input {
background-color: -moz-field }" to white.  I fear this would not be a simple
change to Gecko.

Comment 36

4 months ago
"widget.content.gtk-theme-override" to "breeze" works for me on OpenSuSe tumbleweed with a breeze dark theme.
(In reply to alexpacini90 from comment #36)
> "widget.content.gtk-theme-override" to "breeze" works for me on OpenSuSe
> tumbleweed with a breeze dark theme.

did you test with the native package? opensuse patches firefox so it works natively with kde

Comment 38

4 months ago
Yes, native package, but it was not behaving well with breeze dark on kde.
Posted image idea.png
idea for fix
Flags: needinfo?(iman.stallion)
I think the easy route to fix this bug is by using the 'hack' like my mockup above. If it's checked on a GTK desktop, add "widget.content.gtk-theme-override" with "adwaita:light" value to the config. If it's a KDE desktop, use "breeze". What do you think?
Flags: needinfo?(iman.stallion)

Comment 41

3 months ago
Can I add some user point of view to this thread?
I don't want you to care about my desktop theme preferences!
Sorry for caps, but - WEBSITES ARE NOT READY FOR THIS!

Just make it color:black and background:white, please...

I added "widget.content.gtk-theme-override" it works (looks better, but always ugly), and it's terrible that I had to do it myself...
I believe Firefox should be a bit more user friendly in this part.

Thank you for reading. I hope that ... I lie to myself... nothing will be changed.

Comment 42

3 months ago
"widget.content.gtk-theme-override" with "adwaita:light" stopped working, use "Adwaita" instead.

Updated

2 months ago
Duplicate of this bug: 1517950

Comment 44

a month ago

(In reply to Risman Rangga Pratama from comment #40)

I think the easy route to fix this bug is by using the 'hack' like my mockup
above. If it's checked on a GTK desktop, add
"widget.content.gtk-theme-override" with "adwaita:light" value to the
config. If it's a KDE desktop, use "breeze". What do you think?

(In reply to oxhak from comment #42)

"widget.content.gtk-theme-override" with "adwaita:light" stopped working,
use "Adwaita" instead.

Thank you so much! Pfeew, life is easier now :)

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