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

NEW
Unassigned

Status

()

defect
P3
normal
2 years ago
2 months ago

People

(Reporter: anika.henke, Unassigned)

Tracking

({access, regression})

51 Branch
Points:
---

Firefox Tracking Flags

(firefox53 wontfix, firefox54 wontfix, firefox55 wontfix, firefox56 wontfix, firefox57 fix-optional)

Details

Attachments

(3 attachments)

Reporter

Description

2 years ago
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.
Reporter

Comment 1

2 years ago
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).

Updated

2 years ago
Component: Untriaged → CSS Parsing and Computation
Product: Firefox → Core

Comment 2

2 years ago
Are they recent issues?
Reporter

Comment 3

2 years ago
(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.
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?
Flags: needinfo?(dbolter)
Keywords: access, regression
(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?
Flags: needinfo?(dbolter) → needinfo?(bugs)
(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?
Flags: needinfo?(bugs) → needinfo?(dbolter)
Reporter

Comment 7

2 years ago
(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.
Reporter

Comment 8

2 years ago
(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.
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?
Flags: needinfo?(dbolter)

Comment 10

2 years ago
(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.
(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).
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3
Posted image 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.
Xidorn, is it an intended design or just a bug?
Flags: needinfo?(xidorn+moz)
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.
Flags: needinfo?(xidorn+moz)
Assignee: nobody → ywu
Status: NEW → ASSIGNED
Too late for 54. Mark 54 won't fix.
Duplicate of this bug: 1376516
Assignee: ywu → nobody
Status: ASSIGNED → NEW
Reporter

Comment 17

2 months ago

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?

You need to log in before you can comment on or make changes to this bug.