JDK-4716067 : Drag&Drop state indicator indicates wrong state
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.4.1
  • Priority: P4
  • Status: Closed
  • Resolution: Cannot Reproduce
  • OS: linux
  • CPU: x86
  • Submitted: 2002-07-17
  • Updated: 2004-03-17
  • Resolved: 2004-03-17
Related Reports
Relates :  
Relates :  
Description

Name: dk106046			Date: 07/17/2002

Linux RedHat7.2 and 7.3 with Gnome desktop

java version "1.4.1-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-beta-b13)
Java HotSpot(TM) Client VM (build 1.4.1-beta-b13, mixed mode)

1. javac JTextAreaDnD.java, and testClass.java
2. java testClass
3. Select "Drag Source" string with mouse and press left mouse button 
   on selected text and keep it
4. State indicator is changed to droppable with move
5. Move mouse cursor to GNOME Desktop, state indicator is changed to not-droppable
6. Move mouse cursor to the other JTextArea("Drop Target")
7. State indicator should be droppable with move,
   But it's not-droppable with move <== PROBLEM
8. Press Shift or Ctrl key, state indicator is changed to droppable with move/copy

import java.awt.*;
import javax.swing.*;

public class testClass {

    public static void main(String[] args) {

       JFrame frames = new JFrame("JTextArea - Drag Source");

       frames.getContentPane().add(new JTextAreaDnD());

       frames.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);

       frames.setSize(200, 100);

       frames.setLocation(10,10);

       frames.show();
       
       Frame framet = new JFrame("JTextArea - Drag Target");

       framet.getContentPane().add(new JTextAreaDnD());

       framet.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);

       framet.setSize(200,100);

       framet.setLocation(250,10);

       framet.show();

    }

}


and 

import java.awt.*;
import javax.swing.*;

public class JTextAreaDnD extends JTextArea {
    public JTextAreaDnD() {
        super("Draggable Text");
        setDragEnabled(true);
    }
}


======================================================================

Comments
WORK AROUND Name: dk106046 Date: 07/17/2002 You have to use the shift or Ctrl key to change the drop indicator. ======================================================================
24-08-2004

EVALUATION Name: dsR10078 Date: 10/26/2002 I reproduced the bug with 1.4.2b01-b03 on Linux Redhat 7.3 with GNOME desktop. The cause of the problem is that Motif caches the supported drop operations on the drag initiator side and updates it only when the keyboard modifiers state changes or when the drag receiver modifies the set supported operations. When the mouse moves to the GNOME desktop, the desktop becomes the current drag receiver and it responses that no drop operations are allowed. Motif caches this response and when the mouse moves to the other frame, it reports to the Java DnD subsystem that the user selects an unsupported operation. This is propagated to the DropTargetListener registered with the JTextArea, and DropTargetDragEvent.getDropAction() returns ACTION_NONE. JTextArea uses the standard Swing implementation of DropTargetListener provided by the class TransferHandler.DropHandler that checks the user drop action returned from DropTargetDragEvent.getDropAction() and rejects the drag if the action is ACTION_NONE and accepts the drag otherwise. So the drag is rejected and the cursor remains not-droppable. When the keyboard modifiers state changes, Motif updates cached value of the supported operations based on the new modifiers state and reports the new value to Java. DropTargetListener accepts the drag and eventually the drag cursor changes to droppable. Starting with 1.4.2b02 the workaround doesn't work anymore - the drop indicator doesn't change even if Ctrl or Shift is pressed. The difference is a side effect of the fix for 4407521. With this fix the DropTargetDragEvent.getDropAction() permanently returns ACTION_NONE after the drag was rejected. ###@###.### 2002-10-25 ====================================================================== Name: dsR10078 Date: 11/09/2002 The regression introduced with the fix for 4407521 is documented in 4774532 and fixed. So the workaround should work as before. The complete solution to this problem requires changes in Motif DnD code. ###@###.### 2002-11-09 ====================================================================== Name: agR10216 Date: 03/17/2004 This bug isn't reproducible starting with the implementation of XDND protocol and lightweight Motif DnD protocol done under the bug 4638443. ###@###.### 2004-03-17 ======================================================================
17-03-2004

SUGGESTED FIX Name: dsR10078 Date: 11/06/2002 Update the cached value of the supported operation whenever drag moves to a new toplevel. The following patch to the Linux motif workspace resolves the problem: --- lib/Xm/DragC.c Fri Oct 25 18:25:26 2002 *************** *** 2701,2706 **** --- 2701,2707 ---- NewScreen(dc, root); GetDestinationInfo(dc, root, subWindow); + CalculateDragOperation(dc); /* we should special-case the root window */ if (dc->drag.currReceiverInfo->window) ###@###.### 2002-11-06 ======================================================================
06-11-2002