JDK-4521075 : Drag gesture in JAVA different from Windows
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 1.4.0,1.4.1,1.4.2,5.0
  • Priority: P1
  • Status: Resolved
  • Resolution: Fixed
  • OS:
    linux,windows_nt,windows_2000,windows_xp linux,windows_nt,windows_2000,windows_xp
  • CPU: x86
  • Submitted: 2001-10-30
  • Updated: 2017-05-16
  • Resolved: 2005-05-11
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 JDK 6
5.0u5Fixed 6 b36Fixed
Related Reports
Duplicate :  
JDK-4673885 - JCheckBoxes in drag-enabled JTables do not react on every mouse-click
Duplicate :  
JDK-4765280 - RFE: Cannot drag out of a JFileChooser without first selecting a file
Duplicate :  
JDK-4817070 - Must select in JTable then release mouse button before able to drag and drop.
Duplicate :  
JDK-4832979 - Cursor does not appear in JTable cell editor component when setDragEnabled(true)
Duplicate :  
JDK-5052476 - Boolean CheckBox in table does not behave properly /w drag and drop enabled
Duplicate :  
JDK-4803783 - Reopen 4425334: drag in JList requires two mouse gestures
Relates :  
JDK-6524428 - BasicTableUI mouse listener doesn't check mouseEvent.isConsumed()
Relates :  
JDK-4501652 - Attributes of columns should not depend on the position. (JFileChooser)
Relates :  
JDK-6342398 - More flexibility in specifying drag over changes to a component
Relates :  
JDK-4425334 - Unable to drag from JList, if mouse btn not released till it's dropped on target
Relates :  
JDK-4380088 - Cannot drag and drop multiple items
Relates :  
JDK-6341549 - Make sun.swing.enableImprovedDragGesture a trusted property for Java Web Start.
Description
Name: ddT132432			Date: 10/30/2001


Microsoft Windows 2000 [Version 5.00.2195]
C:\>java -version
java version "1.4.0-beta2"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta2-b77)
Java HotSpot(TM) Client VM (build 1.4.0-beta2-b77, mixed mode)


Windows Explorer allows starting dragging a node in the file tree in one click
where 2 successive clicks are required in Java 1.4 when the default support for
DnD is enabled for an unselected node in a JTree. I suppose that it would be
the same for any other component with the default DnD support behavior.

If a JTree is used as a source for a drag operation, to drag a node from the
tree, the user needs to click once on the unselected node, release the mouse
button and click a second time, keep the button down to start dragging the node.

With Windows Explorer, if the user clicks on an unselected element and keep the
mouse button down, the user can start dragging that element immediately.
(Review ID: 134499) 
======================================================================
###@###.### 10/12/04 18:59 GMT
Comments
EVALUATION Name: biR10147 Date: 10/31/2001 Default drag support for AWT components (Button, List, etc.) starts a drag operation even if drag gesture was recognized on the item which wasn't selected before the drag gesture was initiated. However, several Swing components, including JTree, are documented to behave by default the different way: they will initiate the drag only if drag gesture was initiated on selection. Documentation for JTree.setDragEnabled() says: "When automatic drag handling is enabled, most look and feels begin a drag-and-drop operation whenever the user presses the mouse button over a selection and then moves the mouse a few pixels." So the observed behavior matches the documentation. Anyway, it's up to Swing team to decide if they want their components to behave this way. Reassigning to classes_swing. ###@###.### ====================================================================== Wow, this is a popular bug. Comitting to tiger. ###@###.### 2002-10-18 Note that we should also deal with JList and JTable. I am closing a bug on JList as a duplicate of this one. ###@###.### 2003-01-16 Should investigate 4801246 along with this bug. I beleive they are related. ###@###.### 2003-01-16 The problem here is clear - our DnD implementation doesn't act as most users would expect. Under many circumstances, a mouse press should select first and then start dragging. One of the problems we need to overcome in order to fix this is the fact that DnD drag gesture recognition is handled in a separate mouse listener than the one that does selection. This is fine for the old behavior since the two mouse listeners don't need much communication - the gesture recognizer processes events first (if something is selected) and consumes them if it doesn't want the selection listener to see them. In order to correct this bug, there needs to be a lot more communication between the selection logic and the gesture recognition logic. Sometimes a selection needs to happen first. In order to facilitate this, we will collapse the logic down into one listener. Each component will have a single selection listener. The drag gesture recognition code will be moved into a static helper class that the selection listeners can call into _when_appropriate_. Doing it this way allows the event to be seen first by the selection listener, and logic there can then decide whether or not to give the gesture recognition code a chance at the event. - JTree will be fixed based on this approach. - JList will be fixed based on this approach. - JTextComponents will continue to act as before, only starting a drag when something is already selected. This is what is expected for text. However, the text DnD recognition code will be tweaked to use the new helper class. - JTable will continue to act as before since it is often used in a spreadsheet context. JTable supports dragging to select ranges of cells and therefore it would be wrong to begin a drag unless something is already selected. This is consistent with what other spreadsheet applications do. However - when JTable is used for File selection in JFileChooser, it will be fixed as mentioned above. ###@###.### 2004-05-11 When JTable is in SINGLE_SELECTION mode (for both rows and columns), it's really being used more like a list component. Therefore, my current thinking is that I'll make it support dragging on the first press (like JTree and JList). We'll have to see how this works out. ###@###.### 2004-05-18 Note: It looks like I'll be fixing 4501652 as a side effect of fixing this. If so, I'll close that bug as a duplicate when this is done. ###@###.### 2004-05-18 4501652 will NOT be fixed by this bug. It will be fixed by another fix in tiger. See that bug for details. ###@###.### 2004-06-10 Unfortunately, the fix for this bug did not make Tiger. We continue to make fixing this bug a major priority and the lack of fix to date certainly does not stem from non-interest. The major problem still to overcome is how to solve this in a way that is backward compatible. One of the issues that was encountered is that JTree and JTable allow customization of what mouse clicks start an edit. With this logic being pluggable, it makes it extremely difficult to write drag detection logic in the correct way. It is my current belief that the fix to this bug will require making some assumptions about what developers might do. Unfortunately, that's not something that was safe so late in Tiger. I continue my efforts... ###@###.### 10/12/04 18:59 GMT Fixing this bug is my number one priority for Mustang. I have continued with my previous work and have come even farther. I believe the implementation to be done for JTextComponents, JList and JTable. JTree is next, and I begin work immediately. In order to make JTable work correctly, I had to make some changes in behavior when getDragEnabled() is true: 1) Cell editing will no longer start on mouse presses. It will start only on mouse releases. 2) The value of CellEditor.shouldSelectCell() will be ignored in that cells will always be selected. This is necessary, otherwise they could never be dragged. The method WILL still be called, however, to ensure backward compatibility for those that expect it to be called after editing starts. ###@###.### 2005-04-21 18:55:17 GMT I've now completed the implementation for JTree. I've made similar changes to those made in JTable that change the behavior when getDragEnabled() is true. That is, cell editing will start on mouse releases. But it will only start if no selection change was made by the press. This is to remain compatible with DefaultTreeCellEditor. Also, the value of CellEditor.shouldSelectCell() will also be ignored in that cells will always be selected. This is for the same reasons outlined above. Lastly, as part of this fix, I've also made some changes to the Metal version of JFileChooser. It will now behave much more like the Windows L&F JFileChooser in terms of selection, activation, and drag recognition. ###@###.### 2005-04-27 16:40:42 GMT This change will be backported to a 5.0 update release, to be enabled by a system property, "sun.swing.enableImprovedDragGesture". Example: java -Dsun.swing.enableImprovedDragGesture APP_CLASS_NAME ###@###.### 2005-05-03 17:15:56 GMT
03-05-2005