Name: gm110360			Date: 08/31/2004


FULL PRODUCT VERSION :
on RH:
java version "1.4.2_03"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_03-b02)
Java HotSpot(TM) Client VM (build 1.4.2_03-b02, mixed mode)

Debian:
java version "1.4.2-rc1"
Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1)
Java HotSpot(TM) Client VM (build Blackdown-1.4.2-rc1, mixed mode)

on FreeBSD:
java version "1.4.2-p6"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-p6-root_23_feb_2004_13_28)
Java HotSpot(TM) Client VM (build 1.4.2-p6-root_23_feb_2004_13_28, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Rerdhat:
Linux gogo 2.4.20-8 #1 Thu Mar 13 17:54:28 EST 2003 i686 i686 i386 GNU/Linux

Debian:
Linux gogo 2.6.0-1-686 #1 Mon Jan 12 00:56:03 CET 2004 i686 unknown

FreeBSD:
FreeBSD twiggy 4.9-STABLE FreeBSD 4.9-STABLE #2: Wed Jan 14 17:21:22 EST 2004     root@twiggy:/usr/obj/usr/src/sys/TWIGGY  i386

EXTRA RELEVANT SYSTEM CONFIGURATION :
Tested on Debian with KDE and RH 9.0 with default window manager (Gnome?)

Does not happen on windows.

A DESCRIPTION OF THE PROBLEM :
A modal dialog blocks input from all Frames but a frame can be placed on top of a modal dialog as long as that frame is not the dialog's parent. This can lead to the awkward situation where the user appears to be unable to input any data. If they don't have a soundcard or have the volume down, they will think the application has frozen. I do not consider Java 1.5's "Always On Top" feature to fix this because the dialog should only be on top of other windows that it is "stealing" input from (that is, other windows in the current java VM/application). Furthermore, for modal dialogs (especially ones that are created and displayed in one command such as JOptionPanes) , being on top should be the default.

This behaviour differs from the windows implementation. Windows doesn't let you move or bring any windows to the front when a modal dialog is showing. I think this is the desired behaviour on all implementations, but at the very least if only one window can have input at a time, that window must always be visible to the user!

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
compile & run example code and drag windows around. You will see that it is possible to drag Frame 2 in front of the dialog (but not Frame 1) which can have the effect of making the program appear crashed.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
User should not be able to put Frame 2 in front of dialog.
ACTUAL -
User CAN put Frame 2 in front of dialog.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import javax.swing.*;

public class LostJDialog
{
        public static void main( String args[] )
        {
                JFrame jf1 = new JFrame( "Frame 1" );
                JFrame jf2 = new JFrame( "Frame 2" );
                jf1.getContentPane().add( new JLabel( "Frame 1" ) );
                jf2.getContentPane().add( new JLabel( "Frame 2" ) );
                jf1.pack();
                jf1.show();
                jf2.pack();
                jf2.show();

                JDialog jd = new JDialog( jf1, "dialog", true );

                jd.getContentPane().add( new JLabel("dialog") );
                jd.pack();
                jd.show();

                System.exit( 0 );
        }
}
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
I tried using some suggestions for simmilar problems from the forums, such as registering listeners to detect when focus is lost and then rerequesting focus, but this could be a problem if the JDialog becomes the parent of another JDialog, for example, and is very difficult or impossible to do with things like JOptionPanes, and JFileChoosers. As with the windows implementation, the user's attention should be directed to the modal Dialog.
(Incident Review ID: 243918) 
======================================================================