Open Bug 1263427 Opened 8 years ago Updated 2 years ago

FF 45.0.1 with dark theme failing showing white fonts on white backgrounds on javascript form fields

Categories

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

x86_64
Linux
defect

Tracking

()

People

(Reporter: je-vv, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: tpi:+)

Attachments

(5 files)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
Build ID: 20160404012304

Steps to reproduce:

Access my bank account which relies a lot on javascript and includes javascript form fields.

Also notice a opposed but similar behavior, though easier to notice, on both, selected text on URL toolbar and scrollbar.


Actual results:

When selecting the options on the bank account javascript forms the background is white and the fonts black, as expected, however once selected the fields show with white background and white fonts, making it non possible to visually confirm selections.

Also, FF shows dark selection area on dark backgrond, when selecting text on the URL toolbar, so one can't notice the selection.  And the scrollbar is dark on top of a dark background, making it not possible to manage it correctly (just guessing).


Expected results:

I would have expected the fields to show up with white background and black fonts, or the other way around, dark background and clear fonts.

I'm using GnomishDark theme and GTK+3.  And I'm noticing the failure until now with FF 45.0.1 and gtk-3 3.20.2.

I couldn't mozregress this because the failure always shows up even on FF 41 on mozzregression, which might be due to the fact I'm using gtk+3 as opposed to the nightly builds offered by mozzregression, which are gtk+2, and also because I'm using the following:

% cat .mozilla/firefox/fls5gbxr.default/chrome/userContent.css
input, textarea, select {
	-moz-appearance: none !important;
	background-color: white;
	color: black;
}

a[class="file"],
a[class="dir"],
a[class="symlink"] {
	color: #2EB8E6 !important;
}

a:visited[class="file"],
a:visited[class="dir"],
a:visited[class="symlink"] {
	color: #FF6666 !important;
}

Which obviously it's not present on the mozzregression, and AFAIK, there's no way to make mozregress use that.

There's a similar bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=1158076

But not quite, because I'm noticing this only until now, and not since FF 43.

An additional weird thing, with the same settings I don't see the same behavior on intel graphics, I'm noticing this on nvidia graphics.
OS: Unspecified → Linux
Hardware: Unspecified → x86_64
Oh, what I see different between intel and nvidia graphics is only the javascript form fields with white on top of white.

The URL selection on toolbar misbehavior, and the scrollbar misbehavior is present no matter the graphics.  And this is totally new with gtk+3 3.20.2...  The white on white fields was present even in older gtk+3 (but don't quite remeber the older version for which it was failing).
Component: Untriaged → Widget: Gtk
Product: Firefox → Core
BTW, the scrollbar issues and some selections, when there's dark on top of dark, are not FF exclusive.  Seems like gtk+3 3.20.2 broke dark themes on that regard.

What was there before I upgraded gtk+3, and it's weird that it's seems to be HW dependent, is the javascript form fields on my bank account, which is white on top of white.  This BTW I haven't seen anywhere else.
Blocks: gtk3
Same issue with KDE/Plasma 5 and Arch Linux

 - Selections are white with white text, ignoring global user CSS
 - Scrollbar's handle is invisible
 - Form elements like radio and checkbox are invisible Even on Firefox plugins and not only on webpages!
 - Firefox menus lost all spacing content is crammed.

It is already bad enough that Mozilla ignores since SEVERAL YEARS the fact that Firefox is unable to handle dark system themes and it is applied partially to websites, causing dark text on dark BG or light text on light BG and everyone using a dark theme is forced to use global user CSS to fix it... now it got out of hand completely.

Right now I'm forced to use Chrome for several things because there is no way to make certain form elements/text visible under Firefox and I can't use these websites.
Attached image ff-broken-01.png
Attached image ff-broken-02.png
Attached image ff-broken-03.png
Attached image ff-broken-04.png
Attached several annotated screenshots of the tons of problems. There are more issue than I listed in my previous comment.

Please raise this bug to critical because it makes several websites unusable completely.

Mozilla, it is time you finally fix FF on dark themes after ignoring us for years!
Upgraded today to firefox-45.0.2-1-x86_64 and gtk3-3.20.3-1-x86_64, nothing is fixed yet.

This is a pretty serious issue, it makes several websites completely unusable thanks to invisible controls and/or text that are usually invisible even in code inspect.

I'm forced to run Firefox and Chrome parallel because these crippled sites can only be used in another browser. Why is this bug receiving no attention?
you can disable dark theme specifically for Firefox until it's fixed. It may be a part of an overall widget rewrite (see Bug 1234158). Which distro do you run? If you're distro has gtk3.20 it may also patch apps for it. Fedora and Arch contains Firefox patches for Gtk3.20.
I'm using Arch actually, yet I have these issues. I'm trying to downgrade Firefox right now but could not make older versions run. Light themes are much worse for the eyes, and I look at the screen a lot.
And using a light theme does NOT work around anything. White on white text, invisible form elements and invisible scrollbar still present. Just tested.
OK, for any other Arch user, there is a Firefox binary in AUR compiled against gtk2 which works like a charm for now, until gtk3 is more reliable (thanks to "pb" on Arch forums for the tip): https://aur.archlinux.org/packages/firefox-gtk2-bin/
It worked for me to switch the gtk theme like described here:
https://bbs.archlinux.org/viewtopic.php?id=210815
I agree latest gtk3 broke several things.  And I pretty much indicated at least the scrollbar issue, and perhpas the URL one are due to that.

However the javascript forms fields on my bank account (white on white) are not due to that.  That was there before gtk3 3.20.2...

Also, it started on FF 45.  Not before (I just confirmed that).

So I'm not complaining on general gtk3 stuff, specially if that also manifest on several other applications, like midori, gnome-mpv, etc.  The major issue I'm facing with my bank account and FF seems to be FF exclusive...
Summary: FF 45.0.1 with dark theme failing showing white fonts on white backgrounds on javascript fonts, and showing dark selections on URL toolbar on dark background, and dark scrollbar on dark background → FF 45.0.1 with dark theme failing showing white fonts on white backgrounds on javascript fonts, and showing dark selections on URL toolbar on dark background
BTW, as indicated in several some Arch forums, it seems gtk-theme-arc:

https://github.com/horst3180/arc-theme

Fixes several of the gtk3 new issues, including URL, scrollbar, etc.  Unfortunately, as I supposed, not this FF javascript form fileds.  Though with the arc dark theme the fonts are not white on white background, as with GnomishDark, the fonts are still way light.  It seems to me like FF doing in this case.

Bad thing I can't mozregress, :-(
Summary: FF 45.0.1 with dark theme failing showing white fonts on white backgrounds on javascript fonts, and showing dark selections on URL toolbar on dark background → FF 45.0.1 with dark theme failing showing white fonts on white backgrounds on javascript form fields
The javascript form fields now are showing back correct again, on FF version 46.0.

So, the bug somehow got corrected with some other fixes for the recently released 46 version.

So this can be closed, and if showing up I'll file a different bug.

Thanks a lot.
Just in case, they show up as black fonts on white background, :-)  Like in the image provided, just with black fonts...
Flags: needinfo?(twalker)
BTW, the issue is still there, only thing is that it got masked through my:

.mozilla/firefox/<profile>.default/chrome/userContent.css

input, textarea, select {
   -moz-appearance: none !important;
   background-color: white;
   color: black;
}

a[class="file"],
a[class="dir"],
a[class="symlink"] {
   color: #2EB8E6 !important;
}

a:visited[class="file"],
a:visited[class="dir"],
a:visited[class="symlink"] {
   color: #FF6666 !important;
}

Apparently when filing this one, the css was not being taken into account, and now it is (48.0.1 now)...  It would be best though if there's no need for such configurations, and dark themes would play nice by default:

https://wiki.archlinux.org/index.php/firefox#Unreadable_input_fields_with_dark_GTK.2B_themes
This is still present with latest Nightly 53.0a1, 20161116030212 on Ubuntu in High contrast theme. It's not completely unusable.  What I see is light grey text on white background. Hovering a menu list item produces white text on black background.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(twalker)
Priority: -- → P3
Whiteboard: tpi:+
Version: 45 Branch → Trunk
Yeah, this all messed up with FF 54+ (currently 54.0.1 on Arch)...  Now changing the input in:

.mozilla/firefox/fls5gbxr.default/chrome/userContent.css

Is no longer possible, because several things break for different web pages requiring user input...  And the current suggestion for a safe input modification is:

input:not(.tactile-searchbox-input):not(.urlbar-input):not(.textbox-input):not(.form-control):not([type='checkbox']):not([type='radio'])

Which still keeps light gray text on white background for selected text and text to be input...  So now there's not even a user *.css solution, :(

So I totally dropped userContent.css, since it's useless.  But then I have a broken FF for user input requested by web pages since I really don't like light themes...
We have a partial fix for that at Firefox 55 (see https://bugzilla.mozilla.org/show_bug.cgi?id=1158076#c137) but it still has some glitches as some web content is rendered by main process so the dark/light theme is not separated completely.
Well, tried it already...  didn't work out, :(  Perhaps my bank account is part of those including such web content, :(
I meant, on FF 55, :)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: