JDK-4655513 : TransferHandler doesn't recognize ACTION_LINK as a valid drop action
  • Type: Enhancement
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 1.4.0
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_2000
  • CPU: x86
  • Submitted: 2002-03-20
  • Updated: 2003-04-12
  • Resolved: 2002-08-23
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_03 03Fixed
Related Reports
Relates :  
Description

Name: rmT116609			Date: 03/20/2002


FULL PRODUCT VERSION :
java version "1.4.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92)
Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode)

FULL OPERATING SYSTEM VERSION :
Microsoft Windows 2000 [Version 5.00.2195]

DESCRIPTION OF THE PROBLEM :
Dragging links from IE to my application fails.

Dragging a link/URL from IE 5.5 causes the drag and drop procedure to execute and call canImport() on the drop target. canImport() returns true but TransferHandler fails to recognize DnDConstants.ACTION_LINK as a valid action
for the drop target and hence the drag is rejected. This is because TransferHandler is hardcoded to only recognize actions COPY or MOVE.

 Refer to -
 TransferHandler.java:617
 (TransferHandler:DropHandler.actionSupported())

    private static class DropHandler implements
DropTargetListener, Serializable {
        
        private boolean canImport;
        
        private boolean actionSupported(int action) {
617:        return (action & COPY_OR_MOVE) != NONE;
        }
//---------------------------------------------------------|
// At this point
// action = 0x40000000( DnDConstants.ACTION_LINK)and
// COPY_OR_MOVE = 0x3(DnDConstants.ACTION_COPY_OR_MOVE)
//
// hence actionPerformed() returns false and
// the drag is rejected at line 636.
//
// 636:  if (canImport && actionSupported(dropAction)) {
//           e.acceptDrag(dropAction);
//       } else {
//           e.rejectDrag();
//
//---------------------------------------------------------|


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Try dragging a link from IE 5.5 (has nothing to do with IE version) to an application which accepts a DataFlavor with a MIME type of
"application/x-java-url; class=java.net.URL".


This bug can be reproduced always.


My problem is as follows - 

- I have a GUI component which knows and accepts the data flavor in which URL's from IE are provided in, and has DnDConstants.ACTION_LINK as one of the 
actions but the drag operation still gets aborted.

- I am using the TransferHandler class for implementing drag and drop in my application as  this is the recommended way to implement drag and drop in JDK 1.4.

To illustrate the issue, please download and run my example code from

  http://www.geocities.com/vjsvohra

when I drag a link from IE to the JTextArea component (MyText) in the program, the component understands  and accepts the data flavor of the dragged URL (as 
you can make out from the debug messages). MyText's  canImport() returns true, but the problem comes in when the listeners setup by TransferHandler and it's
supporting classes don't recognize  DnDConstants.ACTION_LINK as a valid action and abort the drag.

This happens in TransferHandler's private inner class 'DropHandler' which is hard coded to recognize  COPY_OR_MOVE as the only valid actions ( method - 
actionSupported() ).

CUSTOMER WORKAROUND :
TransferHandler.java:622

    public void dragEnter(DropTargetDragEvent e) {
        DataFlavor[] flavors = e.getCurrentDataFlavors();

        JComponent c = (JComponent)e.getDropTargetContext
().getComponent();
        TransferHandler importer = c.getTransferHandler();
        
        if (importer != null && importer.canImport(c,
flavors)) {
            canImport = true;
        } else {
            canImport = false;
        }
        
        int dropAction = e.getDropAction();
        
        if (canImport && actionSupported(dropAction)) {
//---------------------------------------------------------|
// At this point, for a drop to be valid canImport should
// be true and the drop target should accept the current
// action
//
// One solution is to replace the above if condition with
//
// if( canImport &&
//     ((importer.getSourceActions() & dropAction)!=NONE))
//
//---------------------------------------------------------|
            e.acceptDrag(dropAction);
        } else {
            e.rejectDrag();
        }
    }


(Review ID: 139022) 
======================================================================

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.4.0_03 1.4.1_02 mantis mantis-b02 FIXED IN: 1.4.0_03 1.4.1_02 mantis mantis-b02 INTEGRATED IN: 1.4.0_03 1.4.1_02 mantis mantis-b02 tiger-b06
2004-06-14

EVALUATION Name: dsR10078 Date: 03/21/2002 TransferHandler belongs to Swing. ###@###.### 2002-03-21 ====================================================================== It would be nice for TransferHandler to support ACTION_LINK, however that has not yet been included in the design. ACTION_LINK cannot necessarily be handled in the same manner as COPY and MOVE as they are both simple imports of data. This is really an RFE and something we will think about more for tiger. ###@###.### 2002-04-01 To satisfy this escalated bug, the following will be the new behavior. TransferHandler will now relax its current constraints and support transfers of type ACTION_LINK. However, it will simply import them as it would with a cut or a copy (only if it can support one of the data types offered). A new RFE, 4726410, has been opened to request API support for link actions. ###@###.### 2002-08-05 One more thing to add on this bug. I just noticed in the comments section that there was mention of a second bug. This other bug manifests itself as an NPE in BasicTableUI. I have opened up another bug on that issue (4735546). ###@###.### 2002-08-22
2002-08-22