when browser.display.use_document_colors=0 and browser.display.foreground_color='#fff' and browser.display.background_color='#000' input elements have BLACK text on black background (ie unreadable) if border-radius was defined via css or if border:none

NEW
Unassigned

Status

()

Core
CSS Parsing and Computation
5 years ago
9 months ago

People

(Reporter: Vlad, Unassigned)

Tracking

Trunk
x86_64
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [DUPEME?][bugday-20140210])

Attachments

(1 attachment)

1.92 KB, text/html
Details
(Reporter)

Description

5 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20100101 Firefox/17.0
Build ID: 20121128204232

Steps to reproduce:

I've unchecked "allow pages to use custom colors" in Prefernces, and told to use "white" as text color and "black" as background color.



Actual results:

browser.display.use_document_colors=0 and browser.display.foreground_color='#fff' and browser.display.background_color='#000' input type=submit has BLACK text on black background (i.e. unreadable)

This problem exists almost on any web page with every input type=text

This became broken since mozilla 8.0 or so. It was working as expected in mozilla firefox 3.5 and below


Expected results:

white text on black background on submit button and in query string entry.

Comment 1

5 years ago
With Firefox 20 and
browser.display.use_document_colors=false
browser.display.foreground_color='#fff'
browser.display.background_color='#000'
I'm not able to reproduce the issue. Submit button is with black text and gray background: http://i.imgur.com/D0tda.jpg

Comment 2

5 years ago
Vlad, do you have an example of such a page?  What is your desktop shell color theme like?

I’ve tried the settings with 2013-01-07-03-09-32-mozilla-central-firefox-20.0a1.en-US.linux-x86_64 and the Darklooks GTK theme (with the Shiki-Dust theme which makes content areas black on white, they make every other line in about:config white on white).

That caused black text on dark background at bugzilla.mozilla.org’s and Nightly Start Page’s search fields and Search buttons.

Maybe a duplicate of something like bug 405207.
Whiteboard: DUPEME?

Updated

5 years ago
Flags: needinfo?(arch.hvv)

Comment 3

5 years ago
Oops!  My attempt to reproduce it was affected by something like bug 17978 (text color does not update on system theme change), which seems to be platform-specific.

Comment 4

3 years ago
Reproduced at http://www.google.ru with 2014-02-10-03-02-01-mozilla-central-firefox-30.0a1.en-US.linux-x86_64 (= bug 967069).
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(arch.hvv)
OS: Windows 7 → All

Updated

3 years ago
Duplicate of this bug: 967069

Updated

3 years ago
Component: Untriaged → CSS Parsing and Computation
Product: Firefox → Core
Whiteboard: DUPEME? → [DUPEME?][bugday-20140210]
(Reporter)

Comment 6

3 years ago
I found the conditions to reproduce the bug.

If stylesheet for control specifies border-radius (even if it's 0px) or disables border completely (border:none) (and then resets the border with e.g. "border:solid 1px black;" then color of the text is wrong when use_document_colors=0.

Will attach a textcase.
(Reporter)

Comment 7

3 years ago
Created attachment 8373504 [details]
testcase

here is a testcase.
(Reporter)

Updated

3 years ago
Summary: when browser.display.use_document_colors=0 and browser.display.foreground_color='#fff' and browser.display.background_color='#000' input type=submit has BLACK text on black background (i.e. unreadable) → when browser.display.use_document_colors=0 and browser.display.foreground_color='#fff' and browser.display.background_color='#000' input type=submit has BLACK text on black background (ie unreadable) if border-radius was defined via css or if border:none
(Reporter)

Comment 8

3 years ago
Comment on attachment 8373504 [details]
testcase

here is  how it's rendered with use_document_colors=1:  http://i.imgur.com/rLmKXG7.png

here is how it's rendered if use_document_colors=0: http://i.imgur.com/7ve7hA6.png
as you can see, text is  black on black background inside textarea and on button - i.e. it's unreadable.

Comment 9

3 years ago
I want to add some commentary to help you understand the impact of this bug. Users with poor eyesight or visual impairment may need to modify the default colors to increase the visibility of most websites. There are even browser add-ons which assist in quickly switching colors between normal and high-contrast settings.

As a result of this bug, fewer sites are usable with high-contrast colors. This site (bugzilla.mozilla.org) is an example of this! If I switch to a white-on-black high-contrast scheme, this textbox I'm currently typing in becomes black-on-black and is thus impossible to see. I have to use black-on-white, which is much more difficult on the eyes.

Please view this not just as a cosmetic issue but an accessibility issue!

Comment 10

a year ago
David, can you surface this to the right platform folks? I tried to find a regression window, but it seems the behaviour has fluctuated over the 2007-2016 timespan that we're talking about, and it's not clear to me what (if anything) specifically broke this. AFAICT the issue is that we're somehow still honouring the page-set foreground color despite the pref being set to ignore page styles...
Flags: needinfo?(dbolter)
Summary: when browser.display.use_document_colors=0 and browser.display.foreground_color='#fff' and browser.display.background_color='#000' input type=submit has BLACK text on black background (ie unreadable) if border-radius was defined via css or if border:none → when browser.display.use_document_colors=0 and browser.display.foreground_color='#fff' and browser.display.background_color='#000' input elements have BLACK text on black background (ie unreadable) if border-radius was defined via css or if border:none
Version: 17 Branch → Trunk

Updated

a year ago
Duplicate of this bug: 1274383
(In reply to :Gijs Kruitbosch from comment #10)
> (if anything) specifically broke this. AFAICT the issue is that we're
> somehow still honouring the page-set foreground color despite the pref being
> set to ignore page styles...

I'd think it's more likely that we're honoring a color that comes from the OS, that it says it draws inputs using.  (Whereas if there's no border on the input, we also use OS drawing for the background of the input.)

Comment 13

a year ago
(In reply to David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) from comment #12)
> (In reply to :Gijs Kruitbosch from comment #10)
> > (if anything) specifically broke this. AFAICT the issue is that we're
> > somehow still honouring the page-set foreground color despite the pref being
> > set to ignore page styles...
> 
> I'd think it's more likely that we're honoring a color that comes from the
> OS, that it says it draws inputs using.  (Whereas if there's no border on
> the input, we also use OS drawing for the background of the input.)

That's confusing though, when "use system colors" is turned off and custom colors are set, that shouldn't happen... As in, there's an explicit pref for using system colors. Why would we use the system colors if that pref is unset?

Comment 14

a year ago
Regarding "border: none" -- it's pretty dangerous in such a mode, since if a page relies on background colors alone to separate input fields from a background, the inputs become invisible. Perhaps it's a separate issue, but might be useful to consider if border handling will be changed here -- maybe will get that fixed at once.
Comment hidden (typo)
Flags: needinfo?(yzenevich) → needinfo?(dbolter)
Mike there are a number of bugs like this which might fall under the scope of your new platform-ish FF Ux team. We should build an understanding of visual accessibility issues like this one (other examples: bug 343205, bug 1202495, bug 746205, bug 1008583).

I'd like to take a fresh look at how users can/should customize web visuals with you (and Gijs etc).

For now, is there a way we can flag/NI/keyword/whiteboard bugs that might interest your team?
Flags: needinfo?(dbolter) → needinfo?(mconley)
Yep - things that the team should queue for analysis should block platform-ui-team for now.
Blocks: 1273644
Flags: needinfo?(mconley)

Updated

10 months ago
See Also: → bug 727869

Updated

10 months ago
Duplicate of this bug: 727869

Updated

9 months ago
Duplicate of this bug: 1308330

Comment 20

9 months ago
Users go into Windows High Contrast Mode to more easily read the page content. This border-radius:0; on disabled Select elements causes the text to not be easily readable by users with contrast disabilities. 

My bug which was marked as a duplicate of this contains a screen shot of the problem which is not happening in your testcase HTML referenced above. 
https://bugzilla.mozilla.org/show_bug.cgi?id=1308330
You need to log in before you can comment on or make changes to this bug.