JDK-6401996 : REGRESSION: painting of backgrounds spill outside drop down list bounds
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 6
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2006-03-22
  • Updated: 2011-01-19
  • Resolved: 2006-04-12
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 b80Fixed
Related Reports
Relates :  
JDK-4967886 - Swing should provide full double buffering per window
Relates :  
JDK-6405093 - Disabled slider only get partially repainted
Description
A DESCRIPTION OF THE REGRESSION :
The image background got painted outside the drop down list's bounds somehow, and continue to persist even after the drop down list goes away.

REPRODUCIBLE TESTCASE OR STEPS TO REPRODUCE:
(Using NapkinLAF)
1) click to expand a drop down list (within a FileChooser / TableDemo)
2) hover cursor between list of items; you can even scroll if applicable.

RELEASE LAST WORKED:
5.0 Update 6

RELEASE TEST FAILS:
mustang-b70

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Drop down list works as it should.
ACTUAL -
The image background got painted outside the drop down list's bounds somehow, and continue to persist even after the drop down list goes away.

APPLICATION NAME: NapkinLAF	APPLICATION VERSION: 1.0

OBSERVED APPLICATION IMPACT:
It breaking the UI.

Release Regression From : 5.0u6
The above release value was the last known release where this 
bug was known to work. Since then there has been a regression.
Comments
EVALUATION This is the result of Swing's painting infrastructure asking a component to paint beyond it's bounds. Here's the sequence of events: 1. user mouses of elements of ComboBox's list. 2. Mouse over triggers a repaint on JList. 3. RepaintManager services request, invokes JComponent.paintImmediately with the list as an argument. 4. The list isn't opaque, searches for opaque ancestor, finds JPopupMenu and invokes _paintImmediately with it. 5. JPopupMenu is painted. In paintImmediately when the containment hierarchy is walked looking for the first opaque ancestor the clip bounds are not adjusted, only the x/y location is adjusted. This particular problem is surfacing because the list is much bigger than the JPopupMenu, so that paintImmediately ends up being invoked with a region larger than that of the popup menu. This particular code hasn't changed in eons, so why is it now problematic? Prior to true double buffering Swing would paint to a Graphics returned via getGraphics. The returned graphics constrained the painting region to that of the component, so that even though we ended up setting a clip beyond the bounds of the component, the returned Graphics wouldn't allow us to paint outside the real bounds. With double buffering we're not constraining the graphics to the component size, and we end up allowing the components to draw outside their bounds were previously they couldn't. This problem is specific to JPopupMenu as it's always on top (overrides alwaysOnTop to return true). Components that are not always on top have the paint bounds constrained by that of their parents. The fix will be to change JComponent._paintImmediately to clip the passed in region based on the bounds of always on top components.
28-03-2006