JDK-7124530 : [macosx] What is background color of AWT component? (And foreground, for that matter)
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 7u4
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: os_x
  • CPU: generic,x86
  • Submitted: 2011-12-23
  • Updated: 2013-08-22
  • Resolved: 2012-03-23
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 7
7u4 b11Fixed
Related Reports
Duplicate :  
JDK-7132092 - [macosx] Policy Tool Background is different
Duplicate :  
JDK-7124538 - [macosx] Painting: using setForeground/setBackground causes constant redraws even if the app is idle
Description
http://java.net/jira/browse/MACOSX_PORT-608 submitted 2011/10/26 by Yuri Nesterenko
I'm attaching an example with a Button. For this Button, issued setBackround(Color.GREEN) but it was not honored, background was regular off-white. Foreground is honored though.
There's also a Choice, it is even more interesting. Suppose you set background to BLUE and foreground also to BLUE. With Choice you have a compact view with only selected item visible and an open view with a list of items. Now, in compact view you have background as in that Button above, white, and foreground blue. In open view, background is blue and foreground is white.
What it should be? Obviously everywhere else it is just as you set it.
Note that getBackground/getForeground reports my values, not actual.
Note also that in Apple JDK 6 all these colors are totally consistently ignored. I'm not sure we should call it regression!
Comments
Removed affected version 7, because this bug is matched as known failure.
22-08-2013
SUGGESTED FIX http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/aa30a9aebd68
26-01-2012
EVALUATION Author: Yuri Nesterenko Date: 26/Oct/11 12:32 PM Build: b214 AWT_Mixing/Automated/OtherOverlapping/JComboBoxOverlapping.java AWT_Mixing/Automated/OtherOverlapping/JMenuBarOverlapping.java AWT_Mixing/Automated/OtherOverlapping/JPopupMenuOverlapping.java Author: Artem Ananiev Date: 27/Oct/11 05:21 PM Does it cause any JCK tests to fail? Author: maxim.kolmakov Date: 03/Nov/11 05:40 PM I can say that at least interactive tests are not affected. Author: Dmitry Bessonov Date: 04/Nov/11 02:16 PM I would suggest to look at the specification of the method <span class=&quot;nobr&quot;><a href=&quot;http://download.oracle.com/javase/7/docs/api/java/awt/Component.html#setBackground%28java.awt.Color%29&quot;>http://download.oracle.com/javase/7/docs/api/java/awt/Component.html#setBackground%28java.awt.Color%29<sup><img class=&quot;rendericon&quot; src=&quot;/jira/images/icons/linkext7.gif&quot; height=&quot;7&quot; width=&quot;7&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/></sup></a></span> It clearly states that &quot;The background color affects each component differently and the parts of the component that are affected by the background color may differ between operating systems.&quot; This is not a problem of implementation but rather a problem with the JCK test Author: Yuri Nesterenko Date: 07/Nov/11 08:57 AM Build: b216 AWT_Mixing/Automated/GlassPaneOverlapping/JButtonInGlassPaneOverlapping.java AWT_Mixing/Automated/GlassPaneOverlapping/JGlassPaneInternalFrameOverlapping.java AWT_Mixing/Automated/OtherOverlapping/JInternalFrameMoveOverlapping.java AWT_Mixing/Automated/GlassPaneOverlapping/JLabelInGlassPaneOverlapping.java AWT_Mixing/Automated/GlassPaneOverlapping/JListInGlassPaneOverlapping.java AWT_Mixing/Automated/GlassPaneOverlapping/JPanelInGlassPaneOverlapping.java AWT_Mixing/Automated/GlassPaneOverlapping/JProgressBarInGlassPaneOverlapping.java AWT_Mixing/Automated/OtherOverlapping/JScrollPaneOverlapping.java AWT_Mixing/Automated/GlassPaneOverlapping/JSliderInGlassPaneOverlapping.java AWT_Mixing/Automated/GlassPaneOverlapping/JTextAreaInGlassPaneOverlapping.java AWT_Mixing/Automated/GlassPaneOverlapping/JTextFieldInGlassPaneOverlapping.java AWT_Mixing/Automated/GlassPaneOverlapping/JToggleButtonInGlassPaneOverlapping.java AWT_Mixing/Automated/OtherOverlapping/ViewportOverlapping.java Author: Yuri Nesterenko Date: 07/Nov/11 09:05 AM If we would agree that this disregard of user settings is not a bug we still perhaps should consider that <em>reporting</em> this (disregarded) user settings as working may be a bug. I mean, okay, setBackground() has no effect. What about getBackground()? If that would be actual color, a user may still be in control: set color &#8211; check what is here in fact &#8211; use this knowledge. Funny that in 7-th version of JDK we may treat it as an RFE. Author: Dmitry Bessonov Date: 07/Nov/11 01:26 PM My point is that thet there are no issues with the MacOS port implementation - it behaves according to the spec. set/getBackground() consistency is also verified by the JCK tests. They pass. Author: Mike Swingler Date: 07/Nov/11 03:59 PM The AWT is ancient, and I consider the UI widgets to be &quot;legacy&quot; components designed with assumptions that don't make sense in modern user interfaces. As long as the tests acknowledge this fact and make something as tasteless as widget tinting optional, I don't see the problem here.
23-12-2011