United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-4255200 : modal dialog should come to the front

Details
Type:
Bug
Submit Date:
1999-07-19
Status:
Resolved
Updated Date:
2005-05-21
Project Name:
JDK
Resolved Date:
2005-05-21
Component:
client-libs
OS:
linux_redhat_6.2,windows_nt,linux,generic,windows_98,windows_xp,windows_2000
Sub-Component:
java.awt
CPU:
x86,other,generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
1.3.0,1.3.1_06,1.4.2,5.0,5.0u4,6
Fixed Versions:

Related Reports
Duplicate:
Duplicate:
Duplicate:
Duplicate:
Duplicate:
Duplicate:
Relates:
Relates:
Relates:

Sub Tasks

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
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
                                     
2003-04-29
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
                                     
2004-04-26
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
mustang


                                     
2004-09-15



Hardware and Software, Engineered to Work Together