JDK-4292342 : Clicking in an inactive JInternalFrame can cause a begin-drag (96845)
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 1.3.0
  • Priority: P4
  • Status: Closed
  • Resolution: Cannot Reproduce
  • OS: windows_nt
  • CPU: x86
  • Submitted: 1999-11-17
  • Updated: 2005-05-21
  • Resolved: 2005-05-21
Related Reports
Relates :  

Name: skT88420			Date: 11/17/99

Sorry, my bug report wasn't very clear. The printout you see indicates the bug - the fact that dragGestureRecognized is called means that the system thinks that a drag is going on. To make it more apparent, here's a new version that goes ahead and starts the drag process, so you'll see the drag happen.]

Each JInternalFrame in this example contains a JLabel that is a drag source. If you click and release on a JLabel that is in an inactive JInternalFrame, a drag gets initiated, even though you haven't moved the mouse. The drag-cursor appears, and you have to hit Esc to get out of it.

What's happening is that the mouse-pressed is on the JInternalFrame's glass pane, which activates the pane, which causes the glass pane to be hidden. On the next mouse event (mouse-released or mouse-moved), this causes LightweightDispatcher to send the glass pane a mouse-exit event, which gets routed to the JLabel, which causes WMouseDragGestureRecognizer to recognize a drag gesture.

You can prevent this problem by installing your own glass pane, which ignores mouse-exit events (and therefore prevents them from getting sent to the JLabel) when the glass pane is hidden. However, after you do this, drag-and-drop is disabled for the inactive JInternalFrame. That is, you can't mouse-press on a component in an inactive window and drag it (like you can in Windows, for example). This is because the mouse-pressed, and therefore all the mouse-drags, go to the glass pane, instead of the drag source (the JLabel).

I believe that this is a *different* bug than the one described in 4218515.

import java.util.*;
import java.awt.*;
import java.awt.dnd.*;
import java.awt.datatransfer.*;
import javax.swing.*;

public class DesktopTest implements DragGestureListener, DragSourceListener
	public final static void main (String[] args)
		new DesktopTest();

		JFrame f = new JFrame("hi");

		JDesktopPane d = new JDesktopPane();

		createInternalFrame("one", 100, 100, d);
		createInternalFrame("two", 250, 100, d);


	private void createInternalFrame(String title, int x, int y, JDesktopPane d)
		JInternalFrame i = new JInternalFrame();

		JLabel p = new JLabel("HI");
		DragSource dragsource = new DragSource();
										, DnDConstants.ACTION_COPY_OR_MOVE
										, this);

	public void dragGestureRecognized(DragGestureEvent dge)
							, new StringSelection("test")
							, this);

	public void dragDropEnd(DragSourceDropEvent dsde)			{}
	public void dragEnter(DragSourceDragEvent dsde)				{}
	public void dragExit(DragSourceEvent dse)					{}
	public void dragOver(DragSourceDragEvent dsde)				{}
	public void dropActionChanged(DragSourceDragEvent dsde)		{}
(Review ID: 96907) 

EVALUATION Name: keR10081 Date: 10/11/2000 Not reprodicible after focus putback ====================================================================== What worries me with this evaluation is that this bug has nothing to do with focus. Konstantin, can you provide more information about how this got fixed? hania.gajewska@Eng 2001-01-05 From Konstantin: What is interesting with this bug, it is not reproducible on w2k starting from Kestrel, but is reproducible under WinNT and SPARC Solaris. I haven't tested it under Intel Solaris and various Win9x/WinME. I asked Danila about this bug and he says that this is probably an AWT bug, since the same problem is reproducible in test/java/awt/dnd/DnDAcceptanceTest/DnDAcceptanceTest.html when we click on the button. I've applied to have this bug reopened. hania.gajewska@Eng 2001-02-22 Not reproducible on 1.6.0-ea-b37. ###@###.### 2005-05-21 01:24:23 GMT