JDK-6385534 : For Java drag source, choosing an action other than the user action shows a no-drop cursor
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 6
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2006-02-14
  • Updated: 2011-01-19
  • Resolved: 2006-03-15
Related Reports
Duplicate :  
Relates :  
This bug affects a recent Swing DnD enhancement. Please fix it ASAP.

- Please compile and run the attached demo.
(NOTE: Requires Swing's b74 integration to run the attached test,
 but problem is unrelated to Swing changes)

- On the left is a JList drag source with supported actions COPY and MOVE.
- On the right are two JLists that both accept drops.
- The top one chooses the MOVE action (through Swing with acceptDrag(MOVE))
- The bottom one chooses the COPY action (through Swing with acceptDrag(COPY))
- Drag from the source into the top list and it works
- Drag from the source into the bottom list and it shows the NO-DROP cursor
  It still allows drops. But the wrong cursor is shown.
- Drag text from a native text editor (that supports COPY and MOVE) and
  you'll see that the same problem doesn't exist.

The problem is that Java is showing the NO-DROP drop cursor when you choose something other than the user drop action.
This is wrong - you should be able to choose any of the supported source actions, like with a native drag source.

I suspect the problem is the method DragSourceDragEvent.getDropAction(). Right now it does:

return dropAction & targetActions & getDragSourceContext().getSourceActions();

This is wrong, since it shouldn't intersect the user drop action (dropAction).

Changing it to the following fixes the problem:

return targetActions & getDragSourceContext().getSourceActions(); // note that targetActions is really just the single chosen target action


The problem can also be reproduced in another way on Windows XP:

- Launch SwingSet2.
- Launch Microsoft's WordPad
- Select "Enable Dragging" in the options menu
- In the internal frames demo, select text and drag from the text field labeled "Frame title"
- Drag into WordPad.
- WordPad always selects the COPY option. Notice that this causes the NO_DROP cursor.
- HOWEVER, even though the wrong cursor is shown, you can still drop.

EVALUATION This CR is a duplicate of 4869264.

EVALUATION The fact that DragSourceDragEvent.getDropAction() should intersect dropAction was specified in JavaDoc This method returns the logical intersection of the user drop action, the target drop action and the set of drop actions supported by the drag source. Anyhow this cannot prevent us from getting correct results in DragSourceContext.updateCurrentCursor() where we intersect dropAction again to understand which cursor we should show. I would say that the last intersection was superfluous. Looks like the problem indeed very similar to 6388038. Please look at the evaluation to the bug.