Last Comment Bug 825578 - 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
: when browser.display.use_document_colors=0 and browser.display.foreground_col...
Status: NEW
[DUPEME?][bugday-20140210]
:
Product: Core
Classification: Components
Component: CSS Parsing and Computation (show other bugs)
: Trunk
: x86_64 All
-- normal with 1 vote (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Jet Villegas (:jet)
Mentors:
: 727869 967069 1274383 1308330 (view as bug list)
Depends on:
Blocks: platform-ui-team
  Show dependency treegraph
 
Reported: 2012-12-31 01:06 PST by Vlad
Modified: 2016-10-07 10:19 PDT (History)
11 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
testcase (1.92 KB, text/html)
2014-02-10 11:05 PST, Vlad
no flags Details

Description User image Vlad 2012-12-31 01:06:37 PST
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 User image Loic 2012-12-31 06:36:35 PST
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 User image [:Aleksej] 2013-01-08 06:29:21 PST
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.
Comment 3 User image [:Aleksej] 2013-01-08 07:12:12 PST
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 User image [:Aleksej] 2014-02-10 09:16:51 PST
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).
Comment 5 User image [:Aleksej] 2014-02-10 09:17:54 PST
*** Bug 967069 has been marked as a duplicate of this bug. ***
Comment 6 User image Vlad 2014-02-10 11:04:34 PST
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.
Comment 7 User image Vlad 2014-02-10 11:05:43 PST
Created attachment 8373504 [details]
testcase

here is a testcase.
Comment 8 User image Vlad 2014-02-10 11:09:23 PST
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 User image Nathan 2014-10-08 07:26:08 PDT
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 User image :Gijs 2016-05-23 07:33:11 PDT
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...
Comment 11 User image :Gijs 2016-05-23 07:33:36 PDT
*** Bug 1274383 has been marked as a duplicate of this bug. ***
Comment 12 User image David Baron :dbaron: ⌚️UTC-8 2016-05-23 07:37:51 PDT
(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 User image :Gijs 2016-05-23 07:42:44 PDT
(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 User image defanor 2016-05-23 09:02:15 PDT
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 15 User image David Bolter [:davidb] 2016-05-25 13:35:29 PDT Comment hidden (typo)
Comment 16 User image David Bolter [:davidb] 2016-05-26 08:04:23 PDT
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?
Comment 17 User image Mike Conley (:mconley) 2016-05-26 08:33:34 PDT
Yep - things that the team should queue for analysis should block platform-ui-team for now.
Comment 18 User image :Gijs 2016-08-24 05:49:02 PDT
*** Bug 727869 has been marked as a duplicate of this bug. ***
Comment 19 User image :Gijs 2016-10-07 02:43:27 PDT
*** Bug 1308330 has been marked as a duplicate of this bug. ***
Comment 20 User image Randy Becker 2016-10-07 10:19:53 PDT
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

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