FULL PRODUCT VERSION :
java version "1.5.0_03"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_03-b07)
Java HotSpot(TM) Client VM (build 1.5.0_03-b07, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows 2000 [Version 5.00.2195]

A DESCRIPTION OF THE PROBLEM :
When JInternalFrame.setDefaultCloseOperation() is used to set the behavior to DO_NOTHING (e.g. in order to support an "are you sure?" type of dialog box), and the InternalFrameListener.internalFrameClosing() interface method is then used to call dispose() (e.g. if the user answered "yes"), the next lower JInternalFrame does not receive the focus once the top one has been disposed.

This is particularly noticeable when using the Windows L&F, because if the topmost window was maximized, *all* windows are supposed to be maximized, but that behavior is implemented by maximizing windows when they are activated -- which, due to this bug, may never happen... until the user clicks on the inactive window's title bar, which suddenly seems to realize it's supposed to be maximized and snaps to its proper state. (But note that this is *not* an L&F issue; it's just more annoying with the Windows L&F than with the other ones!)

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Compile and run the provided further on. Use the "New Child" menu command twice to create two JInternalFrame instances. Close the topmost one and notice how the next one down fails to be activated.
Next, comment out the section of code delimited by the "THIS IS THE PROBLEMATIC CODE" and "END OF PROBLEMATIC CODE" comments. Repeat all the above steps, and notice how this time, when closing the topmost window, the next one down does get activated.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
When closing a JInternalFrame whose default close operation has been overridden using setDefaultCloseOperation(), the next lower JInternalFrame should be activated.
ACTUAL -
When closing a JInternalFrame whose default close operation has been overridden using setDefaultCloseOperation(), the next lower JInternalFrame is not activated.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
import javax.swing.event.*;

public class TestMdi {
    private static JDesktopPane desktopPane;
    private static int count = 0;

    public static void main(String[] args) {
        try {
            String className =
"com.sun.java.swing.plaf.windows.WindowsLookAndFeel";
            UIManager.setLookAndFeel(className);
        }
        catch (Exception e) {
            e.printStackTrace();
        }

        JFrame frame = new JFrame("MDI Test Frame");

        desktopPane = new JDesktopPane();
        frame.getContentPane().add(desktopPane);
frame.addWindowListener(new WindowAdapter() {
public void windowClosing(WindowEvent e) {
System.exit(0);
}
});

JMenuBar mb = new JMenuBar();
frame.setJMenuBar(mb);

JMenu m = new JMenu("File");
mb.add(m);

JMenuItem mi = new JMenuItem("New Child");
mi.addActionListener(
new ActionListener() {
public void actionPerformed(ActionEvent e) {
JInternalFrame f = new JInternalFrame("Child " +
(++count), true, true, true, true);

// THIS IS THE PROBLEMATIC CODE
f.setDefaultCloseOperation(JInternalFrame.DO_NOTHING_ON_CLOSE);
f.addInternalFrameListener(new InternalFrameAdapter() {
public void internalFrameClosing(InternalFrameEvent e) {
e.getInternalFrame().dispose();
}
});
// END OF PROBLEMATIC CODE

f.setSize(200, 300);
f.setLocation(count * 20, count * 20);
desktopPane.add(f);
f.setVisible(true);
}
});
m.add(mi);

mi = new JMenuItem("Exit");
mi.addActionListener(
new ActionListener() {
public void actionPerformed(ActionEvent e) {
System.exit(0);
}
});
m.add(mi);

        frame.setSize(900, 600);
        frame.setVisible(true);
    }
}

---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
I think the bug happens because when calling dispose() explicitly, rather than relying on the defaultCloseOperation(), there is a beans property that does not get updated, which the L&F and/or the DesktopManager relies upon, but I have not yet managed to create a work-around that actually works yet.
###@###.### 2005-06-21 11:39:39 GMT