JDK-4991597 : Win L&F: Non editable and disabled text components have incorrect background col
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 5.0
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2004-02-10
  • Updated: 2017-05-16
  • Resolved: 2006-05-10
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6 b84Fixed
Related Reports
Duplicate :  
JDK-6255775 - Disabled JFormattedTextField and JTextArea show as white in Windows L&F
Duplicate :  
JDK-5004920 - REGRESSION: non-editable JTextField background color becomes fixed in Win L&F
Relates :  
JDK-4883120 - Win L&F: Bug 4174290 not fixed. Disabled JTextField background should be grey
Relates :  
JDK-6451939 - JTextComponent.setEditable(false) forces change of component's background
Relates :  
JDK-4174290 - Disabled JTextField background should be control colour in Windows L&F
Relates :  
JDK-6420149 - REGRESSION: Non-editable textarea/textpane/editorpane should have white background
Relates :  
JDK-6463612 - 6451939 only fixed for Metal L&F
Description
Name: gm110360			Date: 02/09/2004


FULL PRODUCT VERSION :
1.5 Beta 1

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]

EXTRA RELEVANT SYSTEM CONFIGURATION :
Not Applicable

A DESCRIPTION OF THE PROBLEM :
Using windows XP L&F in swing, Non editable and disabled text components have incorrect background color.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Screenshot comparisons can be seen on the following link:
https://winlaf.dev.java.net/release_0.4.html#Issue15

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
Use the following SWING PATCH/HACK:
https://winlaf.dev.java.net/release_0.4.html
(Incident Review ID: 237454) 
======================================================================
Comments
EVALUATION This is a bug. Finding the "gold standard" in the Windows world for what, exactly, is native look and feel is very difficult to do. I looked at 3 things: * Windows Display Properties dialog * StyleBuilder * Visual C# 2005 (express edition) None of them agreed completely with each other. Visual C# disagreed with itself between design time and runtime. However, one thing is certain, EVERY native/native-ish component set had a different background color set for disabled components, other than white (except for Visual C# at design time). There are several attached screenshots, including some random theme to make sure we are theming properly. Solution ------------- There is currently no code to update the background color of a generic component when its editable/enabled state changes. Each UIDelegate hierarchy is handling this independently. BasicTextFieldUI handles it for text fields. This is the root of the problem. BasicTextFieldUI should not be the one changing the background state depending on the enabled/editable flags. This behavior is common not just among BasicTextFieldUI, BasicPasswordUI and BasicFormattedTextUI, it is also common among BasicEditorPaneUI, BasicTextPaneUI, and BasicTextAreaUI. The one thing to keep in mind, however, is that we want to make this change with respect to WindowsText*UI classes and not the Metal/etc. However, even if MetalText*UI classes don't take advantage of this notification, the main logic for handling enabled/editable events does belong in the BasicTextUI class. When BasicTextUI receives the property change notification for editable/enabled state changes, it will update the component's background color based on one of three values from the UI Defaults table: inactiveBackground disabledBackground background depending, of course, on the state of the component. Note that this code only executes if the developer has not specified a specific background color on their component. If the developer has called textArea.setBackground(), for instance, then we punt. It is up to the developer at that point to attach a listener to the component and update its background as necessary. Alternatively, they can specify the color of the component as a UIResource -- but then when the component goes back to being enabled the color to use will be coming from the UI defaults table. Additions need to be made to the WindowsLookAndFeel class to load the proper colors for these components into the UI Defaults table. Also, as mentioned in this bug report, WindowsXP actually performs incorrectly here. The background color used by C# and other native components is the CONTROL color, rather than the color specified in the theme. Since we are tracking the native LAF, we are mimicking this "bug" in XP.
24-02-2006
EVALUATION Name: anR10225 Date: 02/12/2004 First the XPStyle.getColor() method should return ColorUIResource instead of Color to allow UI change background on 'editable' and 'enabled' properties changes. Second it seems to be a bug in WinXP, that it doesn't use XP theme properties (edit.edittext(disabled).fillcolor and edit.edittext(readonly).fillcolor) for disabled and readonly edit controls. It uses windows CONTROL system color instead. ======================================================================
25-09-2004