JDK-4388802 : Drag and drop is raising exception for JList
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.4.0
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,solaris_2.6,windows_nt
  • CPU: generic,x86,sparc
  • Submitted: 2000-11-14
  • Updated: 2008-11-05
  • Resolved: 2001-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.
Other
1.4.0 betaFixed
Related Reports
Duplicate :  
JDK-4407346 - Merlinb48: InvalidDnDOperationException in Stylepad on Sol2.6
Duplicate :  
JDK-4388203 - stylepad demo throws NullPointerException at BasicDropTargetListener.java:211
Duplicate :  
JDK-4389423 - Default JList DnD support fails with InvalidDnDOperationException
Relates :  
JDK-4643942 - Deadlock while performing "javax.swing.JTextComponent.copy"
Relates :  
JDK-4558745 - Deadlock occurs while copying
Relates :  
JDK-4527596 - drag-n-drop operation hangs a java application
Description
Drag and drop operation from JList to JTextField raising exceptions.

In solaris, it is not at all copying the text of selected item of JList.

In windows, it is copying but still throwing exceptions. But it is copying only after requesting focus for the JTextField before doing drag and drop operation.

Find attached test case with the bug report.

To Reproduce the bug :

1) Compile and run the attached Java File.
2) Select any item in the JList. Drag it to JTextField beside it. You'll be getting exceptions on console. No text copied into the textfield.
3) Rerun it again, first select the JTextField, then do step 2. It copies the text into the textfield, but still raises exception.

-----------------------------------------------
stack trace found on Windows:
Exception occurred during event dispatching:
java.awt.dnd.InvalidDnDOperationException: The operation requested cannot be per
formed by the DnD system since it is not in the appropriate state
        at sun.awt.dnd.SunDropTargetContextPeer.setCurrentJVMLocalSourceTransfer
able(SunDropTargetContextPeer.java:114)
        at sun.awt.windows.WDragSourceContextPeer.startDrag(WDragSourceContextPe
er.java:82)
        at java.awt.dnd.DragSource.startDrag(DragSource.java:267)
        at java.awt.dnd.DragSource.startDrag(DragSource.java:366)
        at java.awt.dnd.DragGestureEvent.startDrag(DragGestureEvent.java:187)
        at javax.swing.TransferHandler$DragHandler.dragGestureRecognized(Transfe
rHandler.java:601)
        at java.awt.dnd.DragGestureRecognizer.fireDragGestureRecognized(DragGest
ureRecognizer.java:334)
        at javax.swing.TransferHandler$SwingDragGestureRecognizer.gestured(Trans
ferHandler.java:653)
        at javax.swing.TransferHandler.exportAsDrag(TransferHandler.java:130)
        at javax.swing.plaf.basic.BasicListUI$MouseInputHandler.mouseDragged(Bas
icListUI.java:851)
        at java.awt.Component.processMouseMotionEvent(Component.java:4183)
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: merlin-beta FIXED IN: merlin-beta INTEGRATED IN: merlin-beta VERIFIED IN: merlin-beta
14-06-2004
EVALUATION *; import java.awt.datatransfer.*; import java.awt.dnd.*; public class Test { public static void main(String[] args) { final Frame f = new Frame(); final TextField tf = new DragSourceTextField(); final DropTargetListener dtl = new TestDropTargetAdapter(); tf.setDropTarget(new DropTarget(tf, dtl)); f.add(tf); f.pack(); f.setVisible(true); } } class TestDropTargetAdapter extends DropTargetAdapter { static final Clipboard systemClipboard = Toolkit.getDefaultToolkit().getSystemClipboard(); public void dragOver(DropTargetDragEvent dtde) { systemClipboard.setContents(new StringSelection("TEXT"), null); } public void drop(DropTargetDropEvent dtde) { dtde.rejectDrop(); } } class DragSourceTextField extends TextField implements DragGestureListener { public DragSourceTextField() { super("DragSource"); DragSource ds = DragSource.getDefaultDragSource(); ds.createDefaultDragGestureRecognizer(this, DnDConstants.ACTION_COPY, this); } public void dragGestureRecognized(DragGestureEvent dge) { dge.startDrag(null, new StringSelection("TEXT"), new DragSourceAdapter() {}); } } --------------------------------------------------------------------------------- ###@###.### 2001-02-22 ====================================================================== Remaining evaluation moved to attachment 'evaluation.txt' because it was too long. NO FURTHER EVALUATIONS SHOULD BE APPENDED BELOW THIS LINE.
11-06-2004
EVALUATION The exception produced on Windows happens on the very first drag attempt, and doesn't seem to prevent the drag from occuring. The stack trace shows a problem at the native level, not at the swing level, so this bug is being reassigned to AWT. This report may be a duplicate of 4389423. I cannot reproduce the claimed problems focus. The DND operations do not need or change focus. timothy.prinzing@eng 2000-11-16 Reproducible with merlin b43. On Windows, I see a NullPointerException in javax.swing.plaf.basic.BasicDropTargetListener.dragOver. The 'lastPosition' field is null. On Solaris, I see an InvalidDnDOperationException in sun.awt.motif.MDragSourceContextPeer.startDrag. david.mendenhall@east 2000-12-01 NullPointerException on Windows and IllegalDnDOperationException on Solaris have different causes. On Solaris the test throws an exception with the following stack trace: java.awt.dnd.InvalidDnDOperationException: failed to create native peer at sun.awt.motif.MDragSourceContextPeer.startDrag(MDragSourceContextPeer.java:79) at sun.awt.dnd.SunDragSourceContextPeer.startDrag(SunDragSourceContextPeer.java:97) at java.awt.dnd.DragSource.startDrag(DragSource.java:273) at java.awt.dnd.DragSource.startDrag(DragSource.java:370) at java.awt.dnd.DragGestureEvent.startDrag(DragGestureEvent.java:187) at javax.swing.TransferHandler$DragHandler.dragGestureRecognized(TransferHandler.java:601) at java.awt.dnd.DragGestureRecognizer.fireDragGestureRecognized(DragGestureRecognizer.java:335) at javax.swing.TransferHandler$SwingDragGestureRecognizer.gestured(TransferHandler.java:653) at javax.swing.TransferHandler.exportAsDrag(TransferHandler.java:130) at javax.swing.plaf.basic.BasicDragGestureRecognizer.mouseDragged(BasicDragGestureRecognizer.java:47) at java.awt.AWTEventMulticaster.mouseDragged(AWTEventMulticaster.java:260) at java.awt.Component.processMouseMotionEvent(Component.java:4345) at javax.swing.JComponent.processMouseMotionEvent(JComponent.java:2490) at java.awt.Component.processEvent(Component.java:4131) at java.awt.Container.processEvent(Container.java:1299) at java.awt.Component.dispatchEventImpl(Component.java:2899) at java.awt.Container.dispatchEventImpl(Container.java:1361) at java.awt.Component.dispatchEvent(Component.java:2766) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:3174) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:2888) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:2824) at java.awt.Container.dispatchEventImpl(Container.java:1335) at java.awt.Window.dispatchEventImpl(Window.java:1249) at java.awt.Component.dispatchEvent(Component.java:2766) at java.awt.EventQueue.dispatchEvent(EventQueue.java:437) at java.awt.EventDispatchThread.pumpOneEvent(EventDispatchThread.java:140) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:126) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:121) at java.awt.EventDispatchThread.run(EventDispatchThread.java:99) The exception is thrown, since SwingDragGestureRecognizer uses MOUSE_DRAGGED event as a trigger. With the current implementation the trigger event for the drag operation is required to be a mouse button press. Otherwise drag initiation fails. This requirement is too constraining, since the native Motif DnD system allows to initiate a drag in responce to native X events of several types: ButtonPress, ButtonRelease, KeyRelease, KeyPress, MotionNotify. On Win32 the test throws an exception with the following stack trace: java.lang.NullPointerException at javax.swing.plaf.basic.BasicDropTargetListener.dragOver(BasicDropTargetListener.java:211) at javax.swing.TransferHandler$SwingDropTarget.dragOver(TransferHandler.java:488) at sun.awt.dnd.SunDropTargetContextPeer.processMotionMessage(SunDropTargetContextPeer.java:485) at sun.awt.dnd.SunDropTargetContextPeer.access$600(SunDropTargetContextPeer.java:55) at sun.awt.dnd.SunDropTargetContextPeer$EventDispatcher.dispatchMotionEvent(SunDropTargetContextPeer.java:791) at sun.awt.dnd.SunDropTargetContextPeer$EventDispatcher.dispatchEvent(SunDropTargetContextPeer.java:737) at sun.awt.dnd.SunDropTargetEvent.dispatch(SunDropTargetEvent.java:30) at java.awt.Component.dispatchEventImpl(Component.java:2783) at java.awt.Container.dispatchEventImpl(Container.java:1310) at java.awt.Component.dispatchEvent(Component.java:2765) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:3068) at java.awt.LightweightDispatcher.processDropTargetEvent(Container.java:2849) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:2744) at java.awt.Container.dispatchEventImpl(Container.java:1284) at java.awt.Window.dispatchEventImpl(Window.java:1228) at java.awt.Component.dispatchEvent(Component.java:2765) at java.awt.EventQueue.dispatchEvent(EventQueue.java:423) at java.awt.EventDispatchThread.pumpOneEvent(EventDispatchThread.java:140) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:126) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:121) at java.awt.EventDispatchThread.run(EventDispatchThread.java:99) The exception is thrown when BasicDropTargetListener.dragOver() dereferences lastPosition field which is null. lastPosition is initialized in dragEnter(). The cause is that in case if a lightweight component which initiates a drag has an associated drop target, dragEnter() will not be called on its DropTargetListener. So the next call to dragOver() will throw an exception. When the mouse is dragged onto another drop target, dragEnter() is called on that DropTargetListener, so the drag-and-drop completes successfully. In the test case the drag is initiated by JList which by default has an associated drop target. This regression is introduced with a lightweight dispatching change for DnD. Now we handle drag enter message by posting SunDropTargetEvent with MOUSE_ENTERED id to the native container of the drop target. Then LightweightDispatcher routes it to an appropriate lightweight child. When a drag is initiated by the component which has an associated drop target LightweightDispatcher receives MOUSE_ENTERED when the mouse is over the native container already and so it ignores the event. Note that this scenario is not possible with plain mouse events. Suggested fix: For the first problem i suggest to loosen the checks and allow drag initiation in responce to any native mouse or keyboard button press or mouse motion event as supported by native Motif DnD system. For the second problem i suggest to modify LightweightDispatcher so that it checks for the described scenario and resets its state to propagate MOUSE_ENTERED event properly. ###@###.### 2000-12-16 I looked into this for you. I believe the spec was changed from Motif 1.2 to Motif 2.1 (or 2.0; I'm not sure). The Motif 1.2 source code will only accept ButtonPress events, so your fix will only work on Solaris 7/8 and Linux. It will fail on Solaris 2.6. You will need to determine if we can fix 4388802 on Solaris 2.6. Maybe we can trick Motif into accepting the event just by changing its type to ButtonPress, or maybe we can construct a synthetic ButtonPress event. david.mendenhall@east 2001-01-02 I found that in Motif 1.2 XmDragStart accepts events of all the five types, the only thing that fails is the initial sanity check. I tried to change event type to ButtonPress and it works okay. With this change i have to use GetByteArrayRegion(), so that the original array is not changed. Also there is no much need to delete local references, since the method returns to Java soon. ###@###.### 2001-01-03 Based on comments section, recommiting bug for now. david.mendenhall@east 2001-02-21 Name: dsR10078 Date: 02/22/2001 Here is the investigation of the hang described in the comments section: Full thread dump at the point of hang: "AWT-EventQueue-0" prio=6 tid=0x460258 nid=0x12 waiting on monitor [f3700000..f3701a30] at java.lang.Object.wait(Native Method) - waiting on <f8963a20> (a java.lang.Class) at sun.awt.motif.X11Selection.pGetSelectionOwnership(Native Method) at sun.awt.motif.X11Selection.getSelectionOwnership(X11Selection.java:104) at sun.awt.motif.X11Clipboard.setContents(X11Clipboard.java:55) - locked <f4865138> (a sun.awt.motif.X11Clipboard) at javax.swing.TransferHandler.exportToClipboard(TransferHandler.java:166) at javax.swing.text.JTextComponent$MutableCaretEvent.fire(JTextComponent.java:2888) at javax.swing.text.JTextComponent$MutableCaretEvent.stateChanged(JTextComponent.java:2919) at javax.swing.text.DefaultCaret.fireStateChanged(DefaultCaret.java:583) at javax.swing.text.DefaultCaret.changeCaretPosition(DefaultCaret.java:947) at javax.swing.text.DefaultCaret.handleSetDot(DefaultCaret.java:855) at javax.swing.text.DefaultCaret.setDot(DefaultCaret.java:836) at javax.swing.text.DefaultCaret.setDot(DefaultCaret.java:774) at javax.swing.text.JTextComponent.setCaretPosition(JTextComponent.java:1233) at javax.swing.plaf.basic.BasicTextUI$TextDropTargetListener.updateInsertionLocation(BasicTextUI.java:1930) at javax.swing.plaf.basic.BasicDropTargetListener.dragOver(BasicDropTargetListener.java:213) at javax.swing.TransferHandler$SwingDropTarget.dragOver(TransferHandler.java:498) at sun.awt.dnd.SunDropTargetContextPeer.processMotionMessage(SunDropTargetContextPeer.java:506) at sun.awt.dnd.SunDropTargetContextPeer.access$600(SunDropTargetContextPeer.java:58) at sun.awt.dnd.SunDropTargetContextPeer$EventDispatcher.dispatchMotionEvent(SunDropTargetContextPeer.java:813) - locked <f48ad2b0> (a sun.awt.motif.MDropTargetContextPeer) at sun.awt.dnd.SunDropTargetContextPeer$EventDispatcher.dispatchEvent(SunDropTargetContextPeer.java:770) at sun.awt.dnd.SunDropTargetEvent.dispatch(SunDropTargetEvent.java:32) at java.awt.Component.dispatchEventImpl(Component.java:3345) at java.awt.Container.dispatchEventImpl(Container.java:1361) at java.awt.Component.dispatchEvent(Component.java:3327) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:3175) at java.awt.LightweightDispatcher.processDropTargetEvent(Container.java:2945) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:2839) at java.awt.Container.dispatchEventImpl(Container.java:1335) at java.awt.Window.dispatchEventImpl(Window.java:1338) at java.awt.Component.dispatchEvent(Component.java:3327) at java.awt.EventQueue.dispatchEvent(EventQueue.java:437) at java.awt.EventDispatchThread.pumpOneEvent(EventDispatchThread.java:140) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:126) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:121) at java.awt.EventDispatchThread.run(EventDispatchThread.java:99) "TimerQueue" daemon prio=5 tid=0x45ba58 nid=0x10 waiting on monitor [f3901000..f3901a30] at java.lang.Object.wait(Native Method) - waiting on <f4fd4d38> (a javax.swing.TimerQueue) at javax.swing.TimerQueue.run(TimerQueue.java:234) - locked <f4fd4d38> (a javax.swing.TimerQueue) at java.lang.Thread.run(Thread.java:579) "Thread-2" prio=5 tid=0x28120 nid=0x1 runnable [0..ffbee728] "Thread-0" daemon prio=6 tid=0x393008 nid=0xf waiting on monitor [f3a01000..f3a01a30] at java.lang.Object.wait(Native Method) - waiting on <f4fd4de0> (a java.util.TaskQueue) at java.util.TimerThread.mainLoop(Timer.java:432) - locked <f4fd4de0> (a java.util.TaskQueue) at java.util.TimerThread.run(Timer.java:385) "AWT-Shutdown" prio=6 tid=0x389aa8 nid=0xd waiting on monitor [f3c01000..f3c01a30] at java.lang.Object.wait(Native Method) - waiting on <f4f8f640> (a java.lang.Object) at java.lang.Object.wait(Object.java:425) at sun.awt.AWTAutoShutdown.run(AWTAutoShutdown.java:262) - locked <f4f8f640> (a java.lang.Object) at java.lang.Thread.run(Thread.java:579) "AWT-Motif" daemon prio=6 tid=0x362098 nid=0xc waiting on monitor [f3cff000..f3d01a30] at java.lang.Object.wait(Native Method) - waiting on <f8963a20> (a java.lang.Class) at sun.awt.motif.AWTLockAccess.awtWait(Native Method) at sun.awt.motif.AWTLockAccess.awtWait(AWTLockAccess.java:16) at sun.awt.motif.MToolkitThreadBlockedHandler.enter(MDataTransferer.java:218) at sun.awt.dnd.SunDropTargetContextPeer.handleMotionMessage(SunDropTargetContextPeer.java:451) at sun.awt.motif.MToolkit.run(Native Method) at java.lang.Thread.run(Thread.java:579) "Signal Dispatcher" daemon prio=10 tid=0x9d3e0 nid=0x9 runnable [0..0] "Finalizer" daemon prio=8 tid=0x98da0 nid=0x7 waiting on monitor [f4781000..f4781a30] at java.lang.Object.wait(Native Method) - waiting on <f4f84f08> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:111) - locked <f4f84f08> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:126) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:162) "Reference Handler" daemon prio=10 tid=0x96f10 nid=0x6 waiting on monitor [fa981000..fa981a30] at java.lang.Object.wait(Native Method) - waiting on <f4f84f68> (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:425) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:110) - locked <f4f84f68> (a java.lang.ref.Reference$Lock) "VM Thread" prio=5 tid=0x96240 nid=0x4 runnable "VM Periodic Task Thread" prio=10 tid=0x9caf0 nid=0x8 waiting on monitor The application hangs when the toolkit thread is waiting for the event dispatch thread to process SunDropTargetEvent and the client code processing SunDropTargetEvent calls setContents() on the system clipboard. In order to successfully use Xt selection handling routines we have to update the Xt timestamp (see Bug Id 4085183), so we change a dummy property on awt_root_shell and wait for the toolkit thread to dispatch the PropertyNotify event and update the Xt timestamp. At this point the app locks up, since the toolkit thread is blocked itself. The hang can be reproduced with the following minimized test case: --------------------------------------------------------------------------------- import java.awt.
11-06-2004
PUBLIC COMMENTS It is working fine with JDK1.4beta Build55.
10-06-2004