JDK-6778882 : InternalFrame within glass pane goes below a heavy weight component
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 6u12,7
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic,windows_xp
  • CPU: generic,x86
  • Submitted: 2008-12-02
  • Updated: 2011-03-24
  • Resolved: 2011-03-24
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
7Resolved
Related Reports
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
Testcase provided in the description of 6637655 could be used for reproducing this bug. The behavior is observed with 6u12 b02 PIT build.

The test shows an internal frame on top of a heavy weight button. When internal frame is moved, it goes below the button. On resizing the frame, internal frame comes on top of button.
Failed test:
AWT_Mixing/Automated/OtherOverlapping/ViewportOverlapping.java jtreg

Comments
EVALUATION This problem was fixed together with the fix for 6826074 note that the provided test still may produce small visual artifacts, but this problem is described in 7023013
24-03-2011

EVALUATION Note: the ScrollPane example above may be disregarded - it is tracked under 6826074 beacuse it is quite different issue. The Suggested fix provides a fix that inserts the call to revalidate() method of the InternalFrame in the javax.swing.DefaultDesktopManager.setBoundsForFrame() method. This restores the correct behavior.
03-04-2009

SUGGESTED FIX diff -r 1cb2e3e0631f src/share/classes/javax/swing/DefaultDesktopManager.java --- a/src/share/classes/javax/swing/DefaultDesktopManager.java +++ b/src/share/classes/javax/swing/DefaultDesktopManager.java @@ -431,9 +431,7 @@ public void setBoundsForFrame(JComponent f, int newX, int newY, int newWidth, int newHeight) { boolean didResize = (f.getWidth() != newWidth || f.getHeight() != newHeight); f.setBounds(newX, newY, newWidth, newHeight); - if(didResize) { - f.validate(); - } + f.revalidate(); } /** Convenience method to remove the desktopIcon of <b>f</b> is necessary. */
03-04-2009

EVALUATION The following code reproduces the problem that is caused by invalid containers. It does not use any GlassPane or InternalFrame's at all. import java.awt.BorderLayout; import java.awt.Button; import java.awt.Dimension; import java.awt.FlowLayout; import javax.swing.BorderFactory; import javax.swing.JComponent; import javax.swing.JFrame; import javax.swing.JPanel; import javax.swing.JScrollPane; public class HLMixTest { public static void main(String[] args) { JPanel p = new JPanel(new FlowLayout(FlowLayout.LEFT)); p.add(new Button("Test")); p.setPreferredSize(new Dimension(500, 500)); JScrollPane sp = new JScrollPane(p); JFrame f = new JFrame(); f.getContentPane().add(sp, BorderLayout.CENTER); ((JComponent) f.getContentPane()).setBorder( BorderFactory.createEmptyBorder(50, 50, 50, 50)); f.setSize(400, 400); f.setLocationRelativeTo(null); f.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); f.setVisible(true); } } To reproduce: Drag the scrollbar to make button move out of the viewport, you can see the button does not been clipped. Then resize the frame a little bit, the button will be clipped properly.
18-12-2008

EVALUATION The testcase for 6785497 reveals another way to reproduce the issue. javax.swing.JViewport.setViewPosition - this method calls setLocation but no validate happens later.
16-12-2008

WORK AROUND call to validate on top-level is a possible workaround the issue, the following code works fine for me Toolkit.getDefaultToolkit().addAWTEventListener( new AWTEventListener() { @Override public void eventDispatched(AWTEvent event) { if (event.getID() == MouseEvent.MOUSE_DRAGGED) { frame.validate(); } } }, AWTEvent.MOUSE_MOTION_EVENT_MASK );
11-12-2008

EVALUATION The root cause of the problem that currently HW/LW mixing code ignores invalid "apply shape", that is if a container includes a component and the container is invalid, then the Mixing code will not apply new shape to the component. Current HW/LW Mixing implementation supposes that in this case (when the component is invalid) the container will become valid later and the Mixing code will apply correct shape to the component upon validation request. There are several AWT methods which break the Mixing assumption, these methods are reshape, setFont, setLocale, setVisible, setComponentOrientation, setLabel (perhaps, something else). The methods invalidate all containers of the component and no future validate requests come to the containers. Note that the specification for the methods doesn't say that validate must be called on the containers. The problem appears in Swing's code - javax.swing.DefaultDesktopManager class, dragFrame method This code moves the visible location of the frame being dragged to the location specified (like the testcase does) using the Component.setBounds() call. The call invalidates all parent's tree of the internal frame and future "apply shape" requests for HW components will fail (Note that the fix for 6779670 - "Recursive procedures in the HW/LW Mixing code must traverse parent containers" takes care about traversing all parent containers of the component but the traversal stops once when reach any invalid container). So far we don't have acceptable solution of the problem in 6u12 and I transfer the bug to 6u14 taking into account the following reasons: - the problem is a limitation of the mixing feature; this is not a regression of the feature and doesn't break any functionality, - there is a simple workaround of the problem, the client code should call validate on top-level.
11-12-2008

EVALUATION Another problem reproducible with the test is that the popup menu doesn't overlap the internal frame.
05-12-2008