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.
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?
Did you try to set the background and text colors manually in mozilla or uncheck the dialog box for "use system colors"?
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.
I just downloaded 1.3 and the problem is still present.
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.
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.
This issue has not been fixed in 1.5 either. C'mon, guys.
Still not fixed in 1.6.
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.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → WORKSFORME
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?
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Strange, this should work. (And it does, here.)
Assignee: core.layout.form-controls → nobody
QA Contact: desale → core.layout.form-controls
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?
Not fixed in 1.7.3.
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
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/
Created attachment 287279 [details] Reproduction Does this look reproducible for you? Цatch the attachment. Ё-Моё: since 2003 nobody could reproduce it...
Uh... so we're using the system field and fieldtext colors, last I checked. Is that not working? Mook, do you still see this?
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.
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?
Yes. That's what that video, that I posted about
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?
In both In Firefox 184.108.40.206 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.
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).
Ok, so this is totally not a form controls bug, then.
Status: UNCONFIRMED → NEW
Component: Layout: Form Controls → Widget: Win32
Ever confirmed: true
QA Contact: layout.form-controls → win32
Created attachment 396702 [details] 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.
Created attachment 535537 [details] [diff] [review] 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)
Attachment #535537 - Flags: feedback?(jmathies)
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
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.
(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)
ah ok, no I did not change via manifest, will try tonight and post results.
Re Kai Liu: Confirmed that using ComCtl32 v6 works as you mentioned with all mayhem points :)
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
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.
Attachment #535537 - Flags: feedback?(jmathies) → feedback?(dao)
Attachment #535537 - Flags: feedback?(dao) → feedback?(dbaron)
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?
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.
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
The easiest way to fix I think would be to not use the system field text color at all. (Same as Chrome)
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?
(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.)
> 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.
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.
You need to log in before you can comment on or make changes to this bug.