Open Bug 1393927 Opened 2 years ago Updated 10 months ago
Firefox 55 still use dark GTK theme for web content
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.
2 years ago
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.
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
> 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
Duplicate of bug 1268338?
You need to log in before you can comment on or make changes to this bug.