JDK-4508191 : JOptionPane.showInternalOptionDialog blocks after its enclosing JFrame is closed
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.3.0
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2001-09-27
  • Updated: 2010-07-09
  • Resolved: 2011-03-07
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 7
7 b10Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Description
Name: yyT116575			Date: 09/27/2001


java version "1.3.0_02"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0_02)
Java HotSpot(TM) Client VM (build 1.3.0_02, mixed mode)


  Description of bug:
------------------

JOptionPane.showInternalOptionDialog(...) and its ilk create internal dialogue
boxes designed for a JDesktopPane environment, but unlike JDialog,
JInternalFrame does not provide modal functionality - that is, it does not block
user input to other JInternalFrame objects in the same JDesktopPane.
This particular problem appears when an internal dialogue box appears, courtesy
of showInternalOptionDialog(...) or another such method in JOptionPane, and the
JFrame that contains it is closed before the dialogue is dismissed.  Everything
seems to be closed correctly, but the JOptionPane method never returns.  This
causes problems in our system when it tries to exit, with things hanging
mysteriously and never being terminated.

Sample source code:
------------------

Compile and run the following source code.  Try dismissing the dialogue box,
which will force the system to exit.  Run it again and close the window without
dismissing the dialogue box.  The JFrame will be disposed by a WindowAdapter,
but JOptionPane.showInternalMessageDialog(Component,Object,String,int) will
never return.

/** begin source code **/

import java.awt.event.*;
import javax.swing.*;


public class IFTest extends JFrame {

  public IFTest () {
    super ("Internal Frame test");
    setSize (640, 480);
    setContentPane (new JDesktopPane ());

    // just dispose on exit (the old 1.2 way)
    addWindowListener (new WindowAdapter () {
      public void windowClosing (WindowEvent we) {
        System.out.print ("Disposing of window...");
        dispose ();
        System.out.println ("done.");
      }
    });
  }

  public static void main (String[] args) {

    // somewhere for the internal dialogue box
    IFTest iftest = new IFTest ();
    iftest.setLocation (50, 50); // cascade frame a bit
    iftest.show ();

    // show the internal dialogue box
    JOptionPane.showInternalMessageDialog (
        iftest.getContentPane(),
        "Clicking OK will exit the system.\nClose the window and the system will hang.",
        "Test", JOptionPane.INFORMATION_MESSAGE
    );

    // once that's finished, force an exit
    System.out.println ("OK");
    System.exit (0);
  }

}

/** end source code **/

Suggestions:
-----------

The "correct" behaviour, as I see it, should be either:

  (a) closing the window should force the JOptionPane to return as if the
dialogue box was cancelled; or

  (b) block attempts to close the window if there is an internal (and,
eventually, modal) dialogue box in the JDesktopPane.

Neither of these seems particularly easy to me.

Post Scriptum:
-------------

This behaviour also appears in Beta 2 of the 1.4.0 Java Runtime Environment
(java -version reports: build 1.4.0-beta2-b77, mixed mode).
(Review ID: 132691) 
======================================================================

Comments
SUGGESTED FIX The change above was included to the fix for 6178755, however after the fix for 6518753 another changes are required to fix this issue: --- EventDispatchThread.java 2007-02-19 16:34:28.000000000 +0300 *************** *** 393,398 **** --- 393,404 ---- } public FilterAction acceptEvent(AWTEvent event) { if (modalComponent != null) { + int eventID = event.getID(); + boolean mouseEvent = (eventID >= MouseEvent.MOUSE_FIRST) && + (eventID <= MouseEvent.MOUSE_LAST); + boolean actionEvent = (eventID >= ActionEvent.ACTION_FIRST) && + (eventID <= ActionEvent.ACTION_LAST); + boolean windowClosingEvent = (eventID == WindowEvent.WINDOW_CLOSING); /* * filter out MouseEvent and ActionEvent that's outside * the modalComponent hierarchy. *************** *** 406,419 **** * it is accepted. If heavyweight is the same - we still accept * event and perform further filtering in LightweightDispatcher */ ! return FilterAction.ACCEPT; } - int eventID = event.getID(); - boolean mouseEvent = (eventID >= MouseEvent.MOUSE_FIRST) && - (eventID <= MouseEvent.MOUSE_LAST); - boolean actionEvent = (eventID >= ActionEvent.ACTION_FIRST) && - (eventID <= ActionEvent.ACTION_LAST); - boolean windowClosingEvent = (eventID == WindowEvent.WINDOW_CLOSING); if (mouseEvent || actionEvent || windowClosingEvent) { Object o = event.getSource(); if (o instanceof sun.awt.ModalExclude) { --- 412,419 ---- * it is accepted. If heavyweight is the same - we still accept * event and perform further filtering in LightweightDispatcher */ ! return windowClosingEvent ? FilterAction.REJECT : FilterAction.ACCEPT; } if (mouseEvent || actionEvent || windowClosingEvent) { Object o = event.getSource(); if (o instanceof sun.awt.ModalExclude) {
19-02-2007

EVALUATION There is another CR that is tightly related to this one: 6178755. With the fix for that bug the behaviour of the test is the following. If I close the internal frame the whole application exits because of System.exit() call at the end of the test. At the same time the toplevel JFrame can't be closed because of option pane modality. I'm not sure that this behaviour is just what's expected. If it is, then this bug should be closed after the fix for 6178755 is integrated.
29-09-2006

EVALUATION Although modality improvement has solved reprorted problem I found another one: if I close both a Dialog and a Frame then all application still working but no GUI is visible on the screen. The initial problem goes away : now I can't close that JFrame until Dialog showing.
31-01-2006

SUGGESTED FIX Name: apR10262 Date: 11/13/2003 In Container.java, method startLWModal() there is a code: synchronized (getTreeLock()) { Toolkit.getEventQueue(). postEvent(new PeerEvent(this, pumpEventsForHierarchy, PeerEvent.PRIORITY_EVENT)); while (windowClosingException == null) { try { getTreeLock().wait(); } catch (InterruptedException e) { break; } } } Change "while (windowClosingException == null)" to "while ((windowClosingException == null) && (nativeContainer.modalComp != null))" ======================================================================
17-09-2004

EVALUATION Disposing the frame doesn't stop the application under 1.3.1 or before. This would cause the app to exit on 1.4 due to the AWT shutdown code except for the fact that the OptionPane is waiting. Maybe the startModal method in internal frame should also make sure the parent is visible. ###@###.### 2001-10-23
23-10-2001