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.

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

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.

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.

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).

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.

here is a testcase.

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.

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!

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...

(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.)

(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?

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.

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?

Yep - things that the team should queue for analysis should block platform-ui-team for now.

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