JDK-4633417 : JVM completely locks up when dragging to an app that has a modal dialog showing.
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.4.0
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_2000
  • CPU: x86
  • Submitted: 2002-02-05
  • Updated: 2002-04-05
  • Resolved: 2002-03-14
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.
Other Other
1.4.0_01 01Fixed 1.4.1Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Relates :  
Description

Name: wm7046			Date: 02/05/2002


FULL PRODUCT VERSION :
java version "1.4.0-rc"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-rc-b91)
Java HotSpot(TM) Client VM (build 1.4.0-rc-b91, mixed mode)

FULL OPERATING SYSTEM VERSION :
Microsoft Windows 2000 [Version 5.00.2195]



A DESCRIPTION OF THE PROBLEM :
in Java 1.4, if any DnD is enabled and a modal dialog is
shown, the application locks up completely if a drag is
attempted to the app.

There is a possibly-related bug, 4403757, but that does not
mention locking up.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. create an app that has any DnD-enabled component
(example: JTree).
2. show a modal dialog (example:
JOptionPane.showMessageDialog)
3. Drag from the windows desktop over the app.


EXPECTED VERSUS ACTUAL BEHAVIOR :
expect: no drag allowd
actual: no drag allowed, but application completely locks
up.  Windows task manager needed to kill it.

This bug can be reproduced always.

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

public class TestDrag extends JFrame
{
    public TestDrag()
    {
        super("Test of DnD bug");
        this.setDefaultCloseOperation(EXIT_ON_CLOSE);

        JMenuBar menuBar = new JMenuBar();
        JMenu menu = new JMenu("test");

        menu.add(new JMenuItem(new AlertAction(this)));

        menuBar.add(menu);
        this.setJMenuBar(menuBar);

        JComponent content = new JTree();
        content.setBackground(Color.white);
        content.setOpaque(true);
        content.setPreferredSize(new Dimension(400,300));
        this.getContentPane().add(content);

        this.pack();
    }
    public static void main(String[] args)
    {
        new TestDrag().show();
    }
    public static class AlertAction extends AbstractAction
    {
        private JFrame frame;
        public AlertAction(JFrame frame)
        {
            super("Alert...");
            this.frame = frame;
        }
        public void actionPerformed(ActionEvent e)
        {
            JOptionPane.showMessageDialog(frame, "Try dragging now.", "Howdy",
                    JOptionPane.INFORMATION_MESSAGE);
        }
    }
}
---------- END SOURCE ----------

CUSTOMER WORKAROUND :
none found.
(Review ID: 139032) 
======================================================================

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.4.0_01 hopper FIXED IN: 1.4.0_01 hopper INTEGRATED IN: 1.4.0_01 hopper VERIFIED IN: 1.4.0_01
14-06-2004

PUBLIC COMMENTS ###@###.### 2002-04-05 regression test verified in 1.4.0_01
05-04-2002

EVALUATION Since the report references dnd, I'll assume they meant Drag&Drop rather than AWT. Reassigning to Drag&Drop. Commit to fix in Hopper (hang). ###@###.### 2002-02-05 Name: dsR10078 Date: 02/09/2002 I reproduced the problem with JDK1.4.0rc-b92 on WinNT and Solaris/Linux. The difference for Solaris/Linux is that the drag source app doesn't hang, only the app with the modal dialog hangs. JTree component has an associated drop target by default. When you initiate a drag operation and drag over the application, the drop target associated with the JTree receives drag over notifications from the native DnD system. All native drag notifications are processed on the toolkit thread. To notify the corresponding DropTargetListener the Java DnD system posts a SunDropTargetEvent to the event dispatch thread and blocks the toolkit thread until the SunDropTargetEvent is either dispatched or consume()d. This blocking is needed because the DropTargetListener is allowed to reject drag with DropTargetDragEvent.rejectDrag() or to specify an alternative drop action with DropTargetDragEvent.acceptDrag(). We need to block the toolkit thread until the SunDropTargetEvent is dispatched to communicate the DropTargetListener choice back to the native DnD subsystem and eventually to the drag source. While a modal dialog is shown any mouse, action or drag event that is outside of the dialog hierarchy are filtered out. Note that they are not consume()d, just ignored, so the toolkit thread remains blocked forever. ###@###.### 2002-02-09 ======================================================================
09-02-2002

SUGGESTED FIX Name: dsR10078 Date: 02/09/2002 Explicitly consume() all events that are filtered out while the modal dialog is shown. --- EventDispatchThread.java Sat Feb 9 12:15:47 2002 *************** *** 179,184 **** --- 179,185 ---- } if (c != modalComponent) { eventOK = false; + event.consume(); } } } ###@###.### 2002-02-09 ======================================================================
09-02-2002