1335476 - Inputs are invisible (black on black) when changing colour settings

Status: RESOLVED WORKSFORME

(Core :: CSS Parsing and Computation, defect, P3)

Description

[Anika Henke]

Attachment: reduced-test-case-dark-firefox.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.76 Safari/537.36

Steps to reproduce:

1. Open Firefox's Preferences > Content > Colours...
2. Choose a dark background and a light text colour (e.g. yellow on black is quite common)
3. Make sure "Use system colours" is not ticked
4. Change "Override the colours specified by the page with my selections above" to "Always"
5. Open http://jsbin.com/sibube. The last two examples in there have form elements (in this case text inputs and buttons) which have a background set (to anything but "transparent") and either a border set or unset ("border: none").


Actual results:

The last two examples have completely invisible text as the combination of the styles results in black text on a black background.
Or rather, the text is always black and the background is transparent. And because the overall background is set to black, the transparent input background is black as well.


Expected results:

Either the form elements should follow the user specified colours (yellow text on a black background. Or it should have fixed colours (e.g. black text on a white background).
The latter is how it used to be until Firefox 11 (the bug appeared in Firefox 12).

In any case, the two colours need to be set dependent of each other, either both colours should be flexible or fixed. Whenever a transparent background colour is used, the text colour mustn't be fixed.

Comment 1

[Anika Henke]

Clarifying further... Setting the background to "transparent" is also an issue for the same reason, because the text colour is hard-coded to be black (or whatever the system text colour is).

Comment 2

[Loic]

Are they recent issues?

Comment 3

[Anika Henke]

(In reply to Loic from comment #2)
> Are they recent issues?

They exist since Firefox version 12 until now. I have tested in multiple versions but the version I have most tested with is 51.0.1 (64-bit) on Mac OS. But it also happens on the Windows version.

Comment 4

[Liz Henry (:lizzard)]

This problem is described in Anika's article here: https://accessibility.blog.gov.uk/2017/03/27/how-users-change-colours-on-websites/ -- "any input can become invisible". 

David, something for the accessibility team/triage?

Comment 5

[David Bolter [:davidb] (NeedInfo me for attention)]

(In reply to Anika Henke from comment #0)

> In any case, the two colours need to be set dependent of each other, either
> both colours should be flexible or fixed. Whenever a transparent background
> colour is used, the text colour mustn't be fixed.

I agree. Given our current focus it'll be tough to get attention here soon unless there is an quick fix. Jet is there someone who could take a look?

Comment 6

[Jet Villegas (inactive)]

(In reply to David Bolter [:davidb] from comment #5)
> (In reply to Anika Henke from comment #0)
> 
> > In any case, the two colours need to be set dependent of each other, either
> > both colours should be flexible or fixed. Whenever a transparent background
> > colour is used, the text colour mustn't be fixed.
> 
> I agree. Given our current focus it'll be tough to get attention here soon
> unless there is an quick fix. 

There isn't a quick fix here. Are you able to reproduce these issues when using the recommended accessible High Contrast Themes?

Comment 7

[Anika Henke]

(In reply to Jet Villegas (:jet) from comment #6)
> Are you able to reproduce these issues when
> using the recommended accessible High Contrast Themes?

I'm not sure what is meant by "the recommended accessible High Contrast Themes".
The Windows system settings (Settings > Ease of Access > High Contrast)?

No, there are no issues when using a 'High Contrast' theme from the Windows system settings.
But in that case the Firefox colour settings have zero effect. So, there wouldn't be a point in using them.
And it's Windows-specific. As there isn't a Mac equivalent, it won't help Mac users.

Comment 8

[Anika Henke]

(In reply to Anika Henke from comment #7)
> No, there are no issues when using a 'High Contrast' theme from the Windows
> system settings.

I have to correct myself. There is actually one issue. If you choose the first 'High Contrast' theme and set "Override the colours specified by the page with my selections above" to "Never", then you will also have mostly illegible text. The second, fifth and sixth examples in my reduced test case will be yellow on yellow for the text input and white on yellow for the button. The third is yellow on grey.

Comment 9

[David Bolter [:davidb] (NeedInfo me for attention)]

Thanks Anika. We have lots of bugs filed for Windows High Contrast Mode (HCM) so let's deal with those separately.

I'm not able to follow the steps to reproduce on nightly (Firefox 55) as our UI/Options seem to have changed. Perhaps we avoid this issue now?

Comment 10

[:Gijs (he/him)]

(In reply to David Bolter [:davidb] from comment #9)
> Thanks Anika. We have lots of bugs filed for Windows High Contrast Mode
> (HCM) so let's deal with those separately.
> 
> I'm not able to follow the steps to reproduce on nightly (Firefox 55) as our
> UI/Options seem to have changed. Perhaps we avoid this issue now?

No, the colors section has simply moved to the bottom of the "general" pane (the default one that shows when you open the options). It won't have affected this problem.

Comment 11

[Astley Chen (inactive)]

(In reply to :Gijs from comment #10)
> (In reply to David Bolter [:davidb] from comment #9)
> > Thanks Anika. We have lots of bugs filed for Windows High Contrast Mode
> > (HCM) so let's deal with those separately.
> > 
> > I'm not able to follow the steps to reproduce on nightly (Firefox 55) as our
> > UI/Options seem to have changed. Perhaps we avoid this issue now?
> 
> No, the colors section has simply moved to the bottom of the "general" pane
> (the default one that shows when you open the options). It won't have
> affected this problem.

Follow the STR in comment 0, I can still reproduce this issue on Nightly 55(BID:20170514030207).

Comment 12

[Astley Chen (inactive)]

Attachment: color-setting.png

The content in textarea is rendered in the wrong color.
First line with black color, the following lines in red+black colors.

Comment 13

[Astley Chen (inactive)]

Xidorn, is it an intended design or just a bug?

Comment 14

[Xidorn Quan [:xidorn] UTC+10]

I'm not sure what you question is. The image you attached seems to indicate a different issue, not strictly related to this bug.

IIUC, this bug is about that colors of form controls are not overridden correctly, and thus text in them can be illegible. This is certainly a bug which we should fix.

In the image you attached, all text is legible, but some with different colors overlap each other, which looks like a bug as well. These two bugs may have the same cause, and fixing one may fix the other at the same time, but I would consider them separate issues before further investigation.

Comment 15

[Gerry Chang [:gchang]]

Too late for 54. Mark 54 won't fix.

Comment 17

[Anika Henke]

Attachment: Reduced test case (update April 2019)

I've just rechecked this in Firefox 66 and two of the three invisible cases are now fixed. The only case left which is still producing an invisible input is the last one, i.e. for inputs having both a background colour and a border. The screenshot shows this.

On top of that, I also found that adding -moz-appearance: none or -webkit-appearance: none makes all invisible except the 1st and 4th, i.e. setting any background makes them invisible. Shall I report that as a new bug?

Comment 18

[Anika Henke]

I've just retested in Firefox 84 (on macOS Mojave and Windows 10) and found that everyone of those cases is fixed now. That includes any cases with -moz-appearance: none or -webkit-appearance: none (which were not in the test case).

Comment 19

[:Gijs (he/him)]

(In reply to Anika Henke from comment #18)

I've just retested in Firefox 84 (on macOS Mojave and Windows 10) and found that everyone of those cases is fixed now. That includes any cases with -moz-appearance: none or -webkit-appearance: none (which were not in the test case).

Hurray! I guess we'll close this out...

Comment 20

[Emilio Cobos Álvarez [:emilio]]

Yeah, I think I fixed this in bug 1625036 or such.