JDK-4255200 : modal dialog should come to the front
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.3.0,1.3.1_06,1.4.2,5.0,5.0u4,6
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS:
    generic,linux,linux_redhat_6.2,windows_98,windows_nt,windows_2000,windows_xp generic,linux,linux_redhat_6.2,windows_98,windows_nt,windows_2000,windows_xp
  • CPU: generic,other,x86
  • Submitted: 1999-07-19
  • Updated: 2005-05-21
  • Resolved: 2005-05-21
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 b38Fixed
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Relates :  
Description
Name: skT88420			Date: 07/19/99


If a modal dialog is open, a click to any top-level
window of the application should bring
 the dialog 
to the front.
Otherwise it takes sometimes a lot of shifting 
windows
 around until one finds the modal dialog on the 
desktop.
(Review ID: 85760) 
======================================================================

Name: skT88420			Date: 12/20/99


java version "1.3beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3beta-O)
Java(TM) HotSpot Client VM (build 1.3beta-O, mixed mode)


This happens in both 1.2.2 and 1.3beta.

In the sample below, two JFrames are made, and one modal child dialog of frame
one.

Start the app in windows, and have some other app (a browser etc) running full
screen.

Alt-tab to some other full screen win app, so all the java app is obscured.
Using the task bar in windows, select frame 2. This will bring only frame 2 to
the front, and it will beep, because the modal dialog is still around for frame
1. Users think the gui is locked!

If you choose frame1 (the parent of the modal dialog), it's smart enough to
bring up the modal dialog that's blocking it. This is what needs to happen for
all JFrames that could be switched to.

In my info below I am choosing "does this cause your program to hang?" because
although it's not, my end users think it is and get stuck, sometimes killing
the process unnecessarily.

import javax.swing.*;

public class Modal
{
   public static void main(String args[])
   {
      JFrame frame1 = new JFrame("Frame 1");
      frame1.setSize(new Dimension(200,100));
      frame1.setLocation(0,0);

      JFrame frame2 = new JFrame("Frame 2");
      frame2.setSize(new Dimension(200,100));
      frame2.setLocation(200,0);

      JDialog dlog = new JDialog(frame1, true);
      dlog.setTitle("Modal child of frame 1");
      dlog.setSize(new Dimension(200,100));
      dlog.setLocation(150,50);

      frame1.show();
      frame2.show();
      dlog.show();
   }
}
(Review ID: 99224)
======================================================================

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mustang
15-09-2004

WORK AROUND The work-around is quite easy. Add a Window Listener to the frame(s) that do not own the dialog. When the Listener Event Window Activated occurs check to see if the dialog is displayed and if so bring it toFront. I have modified the sample code from the bug to do just that and it works fine.... ============= import java.awt.*; import java.awt.event.*; import javax.swing.*; public class Modal { public static void main(String args[]) { new Modal(); } Modal() { frame1 = new JFrame("Frame 1"); frame1.setSize(new Dimension(200,100)); frame1.setLocation(0,0); frame2 = new JFrame("Frame 2"); frame2.setSize(new Dimension(200,100)); frame2.setLocation(200,0); Frame2.addWindowListener( new WindowAdapter() { public void windowActivated(WindowEvent e) { onFrameActivated(); } } ); dlog = new JDialog(frame1, true); dlog.setTitle("Modal child of frame 1"); dlog.setSize(new Dimension(200,100)); dlog.setLocation(150,50); frame1.show(); frame2.show(); dlog.show(); } void onFrameActivated() { if (dlog != null) { if (dlog.isShowing()) { dlog.toFront(); } } } JDialog dlog; JFrame frame1; JFrame frame2; } Name: skT88420 Date: 12/20/99 None? (Review ID: 99224) ====================================================================== The above workaround does not hold true any longer. ###@###.### 2004-04-26
26-04-2004

EVALUATION This is certainly a valid usability issue that is worth investigating. The reason why this is a real problem is that currently AWT only supports app-modality (modal dialog blocks input to ALL frames). It does seem that for app modality, clicking on any AWT frame in the taskbar should result in bringing the modal dialog (and associated owner frame) to the front, otherwise the user can get confused very quickly (as described in this report). This behavior (modality and toplevel window mgt) is implemented in the AWT, so I'm reassigning this to the AWT team for evaluation. amy.fowler@Eng 2000-03-23 I would have to disagree that a dialog that is not a child of a paticular frame should come to the front when that paticular frame is clicked. I believe that the dialog should only be modal to it's parent frame and not the application, but that is a seperate issue. Will not fix. richard.ray@eng 2000-03-23 I am reopening this bug for further investiagation and to come up with a work around. richard.ray@eng 2000-04-24 I have come up with a simple work-around. richard.ray@eng 2000-04-26 No plans to change the current behavior. There is no UI precedence that clicking on any frame/window of the application should bring a modal dialog forward. ###@###.### 2002-02-11 It should be mentioned that the work-around only works for the case of clicking on a Frame's taskbar icon. Clicking on an inactive Frame will not activate it if another Frame is parenting a visible modal Dialog, thus no windowActivated() call. In fact, according to Spy++, the ONLY window messages being received on the dialog-less Frame are WM_SETCURSOR messages - no WM_LBUTTONDOWN, no WM_NCLBUTTONDOWN, nothing. It is reported that clicking the taskbar icon for the parent of the modal Dialog brings the Frame to the front but not the Dialog. I see the correct behavior, though - the Frame and Dialog are both brought to the front, with the Dialog on top. I've test from 1.4.1 all the way back to 1.1.8 on Windows 2000. ###@###.### 2002-11-22 We attempted to fix this in mantis, but had to back out the fix due to regressions (e.g.4852561/4852233). ###@###.### 2003-04-29 We plan to fix the problem in mustang. ###@###.### 2004-11-09 13:46:33 GMT Fixed as a part of 4080029. ###@###.### 2005-05-04 11:49:49 GMT
29-04-2003