1620344 - form fields have black/dark text in HCM mode (even with `color:inherit`), making them unreadable in dark HCM themes if they're styled with `background-color:transparent`

Status: NEW

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

Description

[Daniel Holbert [:dholbert]]

STR with a testcase:

(1) Activate HCM, with a light foreground and dark background color.
(a) visit about:preferences, search for "color", click "Colors..."
(b) In the resulting dialog, use the color-pickers for 'Text' and 'Background' to choose light-on-dark, and then choose "Override the colors:...Always" in the dropdown at the bottom.

(2) View the attached testcase.

EXPECTED RESULTS: Text in the forms should be readable.
ACTUAL RESULTS: Text in the input field is not readable (it's black or darkgray, on a dark background, instead of being my chosen [and attempted-to-explicitly-inherit] foreground color).

STR "in the wild" in Firefox's own UI:

(1) Activate HCM, with a light foreground and dark background color.
(2) In Firefox Preferences (about:preferences), type anything into the search box at the top right.

(There are at least two other similarly-affected searchboxes: in the "Applications" section ("Choose how Nightly handles the files you download"), and in the dialog for "Manage cookies and Site Data")

EXPECTED RESULTS: Text in the search field should be readable.
ACTUAL RESULTS: Text in the input field is not readable (it's black, and hence not readable on a dark background).

(Note that the search box in the Firefox preferences has background-color: transparent; color: inherit, from our textbox.css theme file ([here's that file for linux)[https://searchfox.org/mozilla-central/rev/13b081a62d3f3e3e3120f95564529257b0bf451c/toolkit/themes/linux/global/textbox.css#24,29-30], and there are versions for Win/Mac as well).

If this bug turns out to be complex to fix, we might want to change our theming (or preferences code) to get rid of that background:transparent styling.

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: screenshot of testcase 1 (with HCM & dark blue background / yellow foreground)

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: screenshot of the issue this causes in about:preferences (search box becomes unreadable)

Comment 4

[Emilio Cobos Álvarez [:emilio]]

Is this a recent regression?

Comment 5

[Emilio Cobos Álvarez [:emilio]]

In particular, is this a regression from bug 1619701? :)

Comment 6

[Daniel Holbert [:dholbert]]

I don't think so. I can reproduce it in Firefox release (73.0.1).

The attached testcase does look a bit different there -- in particular, all the elements have their normal background (they aren't transparent), and the <select> element is readable. But all the other fields seem to have backplate behind their textual contents, which makes it unreadable (and which goes away and makes things readable if I remove the background: transparent styling).

Comment 7

[Daniel Holbert [:dholbert]]

Attachment: screenshot of testcase in Firefox 73.0.1

Comment 8

[Daniel Holbert [:dholbert]]

To clarify, this is only a problem for widgets that have background: transparent (or more specifically, background-color:transparent)

In the absence of that styling, the widgets render with their own normal background-color (independent of the HCM theme colors), which is typically an appropriate color for their text to be visible on top of.

Comment 9

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug is a regression, but please revert this change in case of error.

Comment 10

[Daniel Holbert [:dholbert]]

Attachment: screenshot of testcase in Nightly 46.0a1 (2016-01-01)

Nope bugbug, this is not known to be a regression.

(As a sanity-check, I tested a >4yo build from 2016-01-01 and I can reproduce there as well. See attached screenshot.)

Comment 11

[Elizabeth Mitchell]

Over at Material Design, we've noticed that FF shows the wrong high contrast mode when a button's background is transparent. Does this repro highlight the same bug as the issue? https://jsbin.com/bidakoweso/edit?html,output

Comment 12

[Emilio Cobos Álvarez [:emilio]]

It's late here so I can look tomorrow, but off hand I don't think that is the same issue.

Button has color: buttontext in the UA sheet. Once you apply color: blue on hover, that gets ignored in forced colors mode so it's the same as if you wrote color: revert. Which ends up here: https://searchfox.org/mozilla-central/rev/b9e7c4300ba972a4c98bf463fc046e8cd9367175/layout/style/res/forms.css#575

So I think that's what you're seeing (those two colors being different, but the background being the same because it is transparent). But it might be worth filing a separate bug with more context of what you're trying to do, it might be that we should consider making those two colors the same even in forced colors mode, or something like that.