Bug ID: 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

JDK 7
7Resolved

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

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

Duplicate :	JDK-6826074 - JScrollPane does not revalidate the component hierarchy after scrolling
Relates :	JDK-7023013 - Hw/Lw painting artifacts
Relates :	JDK-6862117 - JPopup is not visible when invoked on AWTButton
Relates :	JDK-6871485 - Performance optimization of the HW/LW Mixing
Relates :	JDK-6852592 - invalidate() must be smarter
Relates :	JDK-6785497 - PIT : List is not rendered correctly if JScrollPane scrollbar is moved
Relates :	JDK-6637655 - Mixing of heavyweight/lightweight components does not wrk with GlassPane childre