United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6385534 For Java drag source, choosing an action other than the user action shows a no-drop cursor
JDK-6385534 : For Java drag source, choosing an action other than the user action shows a no-drop cursor

Details
Type:
Bug
Submit Date:
2006-02-14
Status:
Closed
Updated Date:
2011-01-19
Project Name:
JDK
Resolved Date:
2006-03-15
Component:
client-libs
OS:
generic
Sub-Component:
java.awt
CPU:
generic
Priority:
P2
Resolution:
Duplicate
Affected Versions:
6
Fixed Versions:

Related Reports
Duplicate:
Relates:

Sub Tasks

Description
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.

                                    

Comments
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.
                                     
2006-03-01
EVALUATION

This CR is a duplicate of 4869264.
                                     
2006-03-03



Hardware and Software, Engineered to Work Together