Closed Bug 1283086 Opened 8 years ago Closed 5 years ago

Some form fields are black on Gtk3 dark themes

Categories

(Core :: Widget: Gtk, defect, P3)

Product:
Core
Component:
Widget: Gtk
Version:
49 Branch
Platform:
Unspecified
Linux
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1527048

People

(Reporter: dxzlabs, Unassigned)

References

(Blocks 1 open bug,
URL
)

Details

(Whiteboard: tpi:+)

Attachments

(3 files)

firefox.png
(deleted), image/png
Details
chromium.png
(deleted), image/png
Details
idea.png
(deleted), image/png
Details
Attached image firefox.png (deleted) — 
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
OS: Unspecified → Linux
Attached image chromium.png (deleted) — 

    
    

    
  
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

    
    

    
  
is it the only website with form affected?

    
    

    
  
(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.

    
    

    
  
/*
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;

    
  
Blocks: gtk3
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
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.

    
    

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

    
    

    
  
(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.

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
(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.

    
    

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

    
    

    
  
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.

    
    

    
  
(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".

    
    

    
  
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.

    
    

    
  
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...

    
    

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

    
    

    
  
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

    
    

    
  
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.

    
    

    
  
(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!

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
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
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: linux-nnt
Flags: needinfo?(karlt)
See Also:  → https://bugzilla.mozilla.org/show_bug.cgi?id=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.

    
    

    
  
"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

    
    

    
  
Yes, native package, but it was not behaving well with breeze dark on kde.

    
    

    
  

      
      
      
      

        Attached image
          
        idea.png (deleted)
        — 
      

    


  
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)

    
    

    
  
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.

    
    

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

    
    

    
  
(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 :)



    
    

    
  
Can this be resolved fixed due to Bug 1527048 being fixed?



    
    

    
  
(In reply to Asif Youssuff from comment #45)




Can this be resolved fixed due to Bug 1527048 being fixed?

Yes, Thanks.




Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: