195533 - background color of text fields should be based on Windows default

Status: RESOLVED WONTFIX

(Core :: Widget: Win32, defect)

Description

[bugzilla]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130

In text boxes, like the one I'm typing in now, the field color should default to
the Windows default field color.  The font color reacts appropriately, but if
you have a light font and a dark background set up, it is difficult to see the
font in a white field.  This works properly in Netscape 7.0 for XP and 98, and
in Mozilla for 98, but NOT in Mozilla for XP.  Lists work properly in XP
Mozilla, as well, as far as I've noticed, it's only in fields where you can type.

Reproducible: Always

Steps to Reproduce:
1. Set the Windows default font color to something light and the background to
something dark.
2. Go to any page with a text field.
3. Squint and swear as you try to enter text into the field.
Actual Results:  
The light colored font is very hard to see.  If I had selected pure white as the
font color, it would be invisible.

Expected Results:  
Defaulted the field color to the Windows default background color, so the
default text will be on an appropriate background.

I noticed this with the Modern theme.  Might mess up with other themes, but I
just did all the above typing and I don't want to do it again...just test with
Modern, the effect is obvious.

Comment 1

[Tim Hill]

Does this just happen if you're using the Windows Luna theme in XP, or does it 
happen with the Windows XP Classic theme too?

Comment 2

[adam dudek]

Did you try to set the background and text colors manually in mozilla or uncheck
the dialog box for "use system colors"?

Comment 3

[bugzilla]

The problem occurs with both the Classic and Modern themes.

It also occurs whether or not the "use system colors" box is checked.

As I said before, it's SORTA working, because I get the correct coloring in list
boxes.  It makes it very difficult to use Mozilla on web-based forums, however,
because you have to do a lot of typing in text boxes, like I'm doing right now.

Comment 4

[bugzilla]

I just downloaded 1.3 and the problem is still present.

Comment 5

[Mike Cowperthwaite]

Under Windows 2000, I am seeing the opposite of this problem; Classic and Orbit 
themes, 1.3 Final and 1.4b.  The TEXTAREA, INPUT and SELECT boxes on this 
Bugzilla page all follow my system background color, but force black for text.

Comment 6

[bugzilla]

This problem still exists in Mozilla 1.4 Release Candidate 2.

Any hope of ever getting this fixed?  The solution has got to be trivial.

Comment 7

[bugzilla]

This issue has not been fixed in 1.5 either.  C'mon, guys.

Comment 8

[bugzilla]

Still not fixed in 1.6.

Comment 9

[Asa Dotzler [:asa]]

worksforme with today's 1.7 branch build on windows XP. I've set my windows
background color to pink and my font color to yellow and this text area has
exactly that. 

Comment 10

[bugzilla]

Sorry, but is it is most definitely NOT fixed in the 1.7 release.

This bug has been around for over a year now.

See you at 1.8...how about some good news for me next time?

Comment 11

[Anne (:annevk)]

Strange, this should work. (And it does, here.)

Comment 12

[bugzilla]

The problem also exists in Firefox, and is actually worse because it uses the
default font color in the address bar, but not the default background color.

Is there any hope of fixing this bug?

Comment 13

[bugzilla]

Not fixed in 1.7.3.

Comment 14

[:Mook]

I can see this, but only if I use Windows XP's theming service (i.e., use the
Windows XP theme with the fat window captions and giant buttons), then set the
window text and background colors.  Using the Windows classic look (i.e., not
making use of Windows XP's theming engine) works for me.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20050102
Firefox/1.0+ (CVS)
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910

Comment 15

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 17

[denisps]

Attachment: Reproduction

Does this look reproducible for you? Цatch the attachment.
Ё-Моё: since 2003 nobody could reproduce it...

Comment 18

[Boris Zbarsky [:bzbarsky]]

Uh...  so we're using the system field and fieldtext colors, last I checked.  Is that not working?

Mook, do you still see this?

Comment 19

[denisps]

Applying style "background-color: -moz-field; color: -moz-fieldtext" to span works fine, and applying "background-color: #000; color: #fff" to input too, but applying "background-color: -moz-field; color: -moz-fieldtext" to the input(which is default) doesn’t change the background  color of the input.

Comment 20

[Boris Zbarsky [:bzbarsky]]

Yes, that's because we're using native-themed controls.

This bug was about the text color following OS preferences and the background color not following them.  Is that still happening?

Comment 21

[denisps]

Yes. That's what that video, that I posted about

Comment 22

[Boris Zbarsky [:bzbarsky]]

OK. What are the steps to reproduce (as text, not as video)?  And are you using Firefox 3 alpha 3 or equivalent Gecko-based browser?

Comment 23

[denisps]

In both In Firefox 2.0.0.9 and Firefox 3.0 alpha 9. In Firefox 3.0 alpha 9 I cant even see a cursor.

To reproduce:
Desktop
  +-Properties
      +-Appearance
          +-Window and buttons: Windows XP Style
          +-Advanced
              +-Item:
                  +-Window
                       +-Color 1: Blue
                       +-Color: White
Open any page that contains <input> with default style and try to type there, also you wont see status-bar text, but it’s not the point.

Although I don’t like this comparison, but IE have correct colors.

Comment 24

[:Mook]

Mozilla/5.0 (Windows; ; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007101600 IceWeasel/3.0a9pre

Yes, I still see this:
- Be on Windows XP using the Luna (fat title bar, blue task bar) visual style
- In control panel, display properties, advanced, set:
 - Window text: white
 - window background: black

The problem is due to -moz-appearance: textfield and whatever it's using to draw (see updated URL field).  It may be a problem in XP's visual styles implementation.  (e.g. themed buttons use pixmaps, and thus don't change colors)

As of this build, dropdowns and and mult-item list boxes also have a white-ish background (but the popups from dropdowns are fine).

Comment 25

[Boris Zbarsky [:bzbarsky]]

Ok, so this is totally not a form controls bug, then.

Comment 26

[Emil Ivanov]

Attachment: testcase

Comment 27

[Emil Ivanov]

Attachment: screenshot with Firefox 3.5.2 and IE8

From what I see, the custom colors changed in Display Properties > Appearance > Advanced, the custom background color inside form elements is user defined only when the border on the element is customized in the page.

If an element have custom border it is no longer 3D element for Windows.
If there is no custom style from the page, the element is in "3D mode" and it inherits those colors, else it inherits the Window colors.

IE8 is closer to Firefox than IE7.

The main difference is that Firefox never changes the main window background.

Comment 28

[Brian R. Bondy [:bbondy]]

Attachment: Patch for field background color - feedback needed

The problem was reproducible exactly as per the original post in the latest code of mozilla-central for me.  I used Win7 default theme (Not Aero) with custom colors.

The attached patch is an idea of how the bug can be fixed.
I'm not sure if this is the desired way or not, but I learnt a lot in the process of getting this patch at least :)
Any guidance or feedback would be highly appreciated.

The patch only has an effect if the setting browser.display.use_system_colors is set to true (by default it is false).
This setting can also be accessed via the use system colors checkbox in Options -> Content -> Colors...

Basically the fix is made in the DrawWidgetBackground function and checks if the current item is 1) a text field (or similar) AND 2) has setting browser.display.use_system_colors==true.
If both of those things are true, it will call ClassicDrawWidgetBackground instead which will draw the background with the system colors.

I also added some code to handle an observer for the pref browser.display.use_system_colors so that the setting can be changed and take effect immediately.

Should a test be made for this?
If so, I was thinking:
- An HTML mochitest.
- Setting the browser.display.use_system_colors setting with the SpecialPowers object.
- Possibly extending nsWindowsShellService (other suggestion?) to have:
  - The Win32 API SetSysColor with COLOR_WINDOW, 
  - The Win32 API GetPixel to ensure the pixel matches
- The mochitest would simply have an <input> element

Other notes:
- On IE9: Whether the use windows colors settings is on or off it colors the text fields with system colors.  The setting only effects background color.
- On Chrome11: I could not find such a setting, seems to always be black text on white background.  I think fully controlled by themes.
- On Opera11: Uses system foreground color but white background
- I found that if you comment out "-moz-appearance: textfield" from forms.css then everything works like it is supposed to.  But theme drawing is not used when this is set.

Open questions:
- Is my reasoning above correct on how it should work?
- Perhaps an additional fix should be made to NOT use system text color foreground color unless browser.display.use_system_colors==true?  
- Maybe it should not use the setting at all and always use the field background system colors? (as is the case in IE9)

Comment 29

[Kai Liu]

I think the problem with this bug is that the whole notion of system colors was really meant to apply to classic Windows, not the new uxthemed Windows of XP and beyond.

Case in point, in Windows 7, using Aero, go into the control panel and change the system colors for "Window" from black-on-white to, say, red-on-green.

Now whip up a quick native Win32 API app, using native controls without any sort of custom drawing and observe the mayhem:
* Multi-line text boxes that are disabled are always black-on-white, regardless of any system color settings.
* Multi-line text boxes that are enabled are now red-on-green.
* Single-line text boxes are red-on-white when unfocused and red-on-green when focused.

Using a non-classic theme with color options that were intended for classic is obviously something that Microsoft never intended to have happen...

IIRC, for these parts that you are referring to, drawing the "background" also includes drawing the border, right?  I don't think that the border was ever a separate part, so switching to the classic widget background also means that we get a classic border, right? (which is desired, since the border here is very much specific to a white-background)

Also, have you played around with GetThemeColor?  I wonder what kinds of colors that will return...
http://msdn.microsoft.com/en-us/library/bb773397.aspx

Comment 30

[Brian R. Bondy [:bbondy]]

In addition to Comment 28, enabling Aero has no effects on colors for any of the browsers I listed, nor on the patch I submitted.

Re Kai Liu:
I made a Native Win32 C++ app with system colors changed, using Aero, but have less mayhem:
- Disabled edit box, works as you mentioned, but it is supposed to use the Win32 color setting of "Disabled Item" and not "Window".
- Single line and multi line edit boxes act the same for me using defined system colors (red on green).

Regarding border, yes you are correct.
I haven't tried using GetThemeColor, I'll try playing with it.

Comment 31

[Kai Liu]

(In reply to comment #30)
> I made a Native Win32 C++ app with system colors changed, using Aero, but
> have less mayhem:

Hmm, and uxtheme is active? (i.e., with a manifest asking for the v6 comctl32 and the comctl32 DLL is in the import table)

Comment 32

[Brian R. Bondy [:bbondy]]

ah ok, no I did not change via manifest, will try tonight and post results.

Comment 33

[Brian R. Bondy [:bbondy]]

Re Kai Liu: 
Confirmed that using ComCtl32 v6 works as you mentioned with all mayhem points :)

Comment 34

[Brian R. Bondy [:bbondy]]

nsUXThemeData::GetThemeColor(eUXEdit, ...

With normal state, and with part:
TMT_FILLCOLOR returns (r,g,b)=(255,255,255)
TMT_BACKGROUND, TMT_WINDOW, TMT_TEXTCOLOR, TMT_WINDOWTEXT fail with error Element not found

http://msdn.microsoft.com/en-us/library/bb773210(v=vs.85).aspx

Comment 35

[Brian R. Bondy [:bbondy]]

I think the ideal way to work, would be to use the system color for controls like textfields whether or not the browser.display.use_system_colors setting is set.

I think this after looking at an XUL file which has a drop down editable menu list and a textfield.  The menu list has the system colors, but the text field has a white background.  I think both should use the system background color for that XUL file.

I think browser.display.use_system_colors should be used only for the background of the page, and controls always use the system color settings.  This is consistent with how IE works as well.  

Please advise if this is the best route and if so I will submit a new patch.

Comment 36

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Sorry for the delay here -- I managed to lose track of this request.

So it looks like this patch is adding a pref that's disabled by default, and currently not intended to change any default behavior.  Most of the time, preferences are the wrong solutions to problems -- we should try to behave correctly by default.

It sounds like the problem being described here is that in some cases, we're choosing a textfield rendering such that the text isn't legible on its background.  When that happens, how are we ending up with the wrong thing?  Is it the background that's different from what other modern Windows apps show, or is it the foreground color that's different?  Or are all Windows apps showing illegible results?

Comment 37

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Er, wait, you're keying off an *existing* preference (which defaults to false).  That makes even less sense to me, since that existing preference controls whether the default text and background for Web content use system preferences for those colors -- and has little to do with what's used for form controls, which have defaults independent from those.

Comment 38

[Brian R. Bondy [:bbondy]]

Ya I agree that the pref shouldn't be used and needs a new patch. 

> It sounds like the problem being described here is that in some cases, we're choosing a textfield rendering such that the text isn't legible on its background.  When that happens,

The problem appears on Windows when a user sets their system field background color to black and their system field text color to white.

> how are we ending up with the wrong thing? 

We are using the system field text color, but not the system field background color.  Resulting on white on white. 

> Is it the background that's different from what other modern Windows apps show, or is it the foreground color that's different? 

It's pretty across the board but here is how each browser works.  
Basically I need to know  if you want to work like IE or like Chrome.

Firefox: Uses white background always but system text font color 
IE9: Uses system background color and system foreground color
Chrome: Always uses white background and black text no matter what your system color settings are.
Opera: Uses white background always but system text font color (Same bug as this)

> Or are all Windows apps showing illegible results?

It's pretty messy overall even across different controls see Comment 29

Comment 39

[Brian R. Bondy [:bbondy]]

The easiest way to fix I think would be to not use the system field text color at all. (Same as Chrome)

Comment 40

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

So my point is that the code your patch is disabling is the theme-based drawing.  So I'm interested less in what other browsers do than it what other more native apps do -- if you change those color preferences, does it affect text widgets in modern Windows apps (which should presumably also be using theme-based drawing), and if so, how?

Comment 41

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(The underlying problem here being that -- in my understanding, at least -- Windows has two different ideas of what a "native" control looks like:  the older color-based one and the newer theme-based one.  We should probably try to stick to the newer theme-based one.)

Comment 42

[Brian R. Bondy [:bbondy]]

> So I'm interested less in what other browsers do than it what other more native apps do

If the system field background and text colors aren't changed you get white background and black text. As soon as they are changed though more native apps will by default act really badly.   I describe below what happens.


Native apps act a little funny by default if those settings are changed:
- Multi line edit controls use the system background color and system text color
- When a multi line edit control gets focus it stays the same

- Multi line edit controls that are read only use white background always and system text color (like our bug here)
- When a multi line edit control gets focus, it stays the same

- Single line edit controls use white background always and system text color (like our bug here)
- When a single line edit control gets focus, it then uses the system background color

- Single line edit controls that are read only use white background always and system text color (like our bug here)
- When a single line edit control that is read only gets focus it stays the same (like our bug)

From my understanding, the settings probably were never meant to be used in XP and beyond once they introduced v6 comctl32.

What I think we should do:
If we are drawing with DrawWidgetBackground and not ClassicDrawWidgetBackground then we should not use the system font color.  We should use black since we're already using white backgrounds always.

Comment 43

[bugzilla]

Thank you all for providing sporadic entertainment for over 10 years.

Actual legitimate thanks to Brian, for being the one person who took the issue seriously.  You really tried, but the power of inertia is strong.

I look forward to another decade of alternately restating the problem, denying that it exists, and ultimately flaming out in a blaze of pedantry.

Just for the record, the bug is still there, exactly as it was the day I reported it, twenty-some versions of Firefox and several Microsoft operating systems later.

Comment 44

[Stephen A Pohl [:spohl]]

We have switched to non-native theming for form controls on all platforms in bug 1535761.