Closed Bug 1393927 Opened 7 years ago Closed 2 years ago

Firefox 55 still use dark GTK theme for web content

Categories

(Core :: Layout: Form Controls, defect, P3)

Product:
Core
Component:
Layout: Form Controls
Version:
55 Branch
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: quentin.gravelines, Unassigned)

Details

Attachments

(1 file)

ff55-white_text_on_white.png
10.70 KB, image/png
Details 
User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0
Build ID: 20170823101153

Steps to reproduce:

I'm using Firefox 55 on Fedora 26 with the Adwaita-dark theme, and on some websites text forms still behave incorrectly. I believe this is the same as this bug report :
https://bugzilla.mozilla.org/show_bug.cgi?id=1158076
I joined a screen from the comment form of a website I often visit to show the issue (there are two lines of white on white text above the selected text, which was also white on white before the selection).


Actual results:

The text I typed in the form appears in white on white, making it unreadable.


Expected results:

The text should have been black on white as expected by the website creator.
Component: Untriaged → Widget: Gtk
Product: Firefox → Core
I also have this issue, breeze-dark on nixos.
Dark theme is used for form inputs often making them unreadable, eg: selects often have black text on a dark background.
This desperately needs to be fixed.  It's been an issue for years now.  It makes using Firefox on Linux a real problem.

Here's another example, of the search options on Reddit.

https://i.imgur.com/hADSkI3.png
Karl, any suggestions on how to triage this? Seems pretty serious but the environments users are listing here seem pretty obscure.
Flags: needinfo?(karlt)
Jim, thanks for acknowledging 

My screenshot in the other post was on Xfce (Xubuntu 16.04) which is far from obscure.  I forgot to mention that in my reply (sorry!)  

Here is the same problem on my home computer running Solus Budgie and Firefox 56.0.2: https://i.imgur.com/RyDTN6P.png

In that screenshot, the big dark rectangle is the right-click context menu.  The input fields are also dark.  

I'm also 95% sure I had this same exact issue on KDE last year.  I've had this issue for years and it's one of the major reasons I've not switched from Chrome yet.


If it's of any help, I did manage to find a workaround that works in 57 beta and nightly.  Setting widget.chrome.allow-gtk-dark-theme to true seems to somewhat fix it for me.  

I would really love to see this finally fixed
Also, the site I took the latest screenshot on was here:
https://www.w3schools.com/html/html_form_input_types.asp

Dark themes that I KNOW expose this issue:  Arc Dark, Adapta Nokto

If I was correct about this happening in KDE too, I would have been using Arc Dark KDE at the time.
gtk-theme-name=Adwaita-dark provides a theme with dark background and light
text.  I assume the web page for attachment 8901314 [details] styles the text input and
so the background is not native.

The reporter is expecting a dark foreground color, even though their theme
typically has dark backgrounds.

Firefox doesn't draw the native background and border when the widget is
styled (for some definition of styled).  It seems reasonable that, if Firefox
is not drawing the native background, then it should not be drawing the native
foreground color.

Widget code does not draw the foreground color.  It does provide the native
text input foreground color, but it does not know whether the associated
widget is styled and so cannot know to provide a different color.
Such a fix would need to be in layout code.

The inverse problem where the author has specified a foreground color
without a background may be more difficult, and so there are other questions
about whether defaulting to natively rendered text inputs is even a good idea.
It would make sandboxing much easier if widgets were not rendered natively
in content, but some other nice default theme would be required.

However, this situation of native foreground color for widget without native
background seems quite fixable from layout code, and so I'll change component.

If this is not a problem with other platforms, then it would be interesting to
know how they avoid it.

Some background:

Since changes in bug 1216658 for Firefox 47, GTK settings
gtk-theme-name=Adwaita and gtk-application-prefer-dark-theme=1 will by default
lead to a light background and dark text in Firefox form fields, because the
second of these is ignored.

With gtk-theme-name=Adwaita-dark, however, the value of
gtk-application-prefer-dark-theme has no effect.

I guess one might argue that widget code should try harder to find a light
theme, but some people prefer dark themes.  Further, some light themes have
dark backgrounds for text input.
Component: Widget: Gtk → Layout: Form Controls
Flags: needinfo?(karlt)
Priority: -- → P3
> so there are other questions about whether defaulting to natively rendered text inputs is even a good idea. It would make sandboxing much easier if widgets were not rendered natively in content, but some other nice default theme would be required.

Agreed completely with the above, this is the crux of the issue. Using OS native inputs is a bad idea for this exact reason. There's no good reason why a user's desktop configuration should have any impact whatsoever on how the web looks. 

I'm fairly certain Chrome uses some sort of internal default inputs as well.  They look exactly the same on Linux, Windows and Mac


Thanks Karl

I entirely disagree with the last comment. I want my colourative configuration of my operating-system to affect how Firefox renders the web. Why should it be treated differently to any alternative interface?

We allow to use system colors to render web content (using Settings > Manage Colors > Use system colors and Override the colors specified by the page with your selections above set to Always).

The color-scheme support should work now properly by affecting websites that support them. This bug should be closed as there's not much else actionable here. Please report new issues as new bugs.

Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: