JDK-4613903 : Selection changes after a selection is dragged
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.4.0,1.4.1
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS:
    generic,solaris_10,windows_98,windows_2000 generic,solaris_10,windows_98,windows_2000
  • CPU: generic,x86,sparc
  • Submitted: 2001-12-14
  • Updated: 2003-04-12
  • Resolved: 2002-09-06
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.2 mantisFixed
Related Reports
Duplicate :  
JDK-4748394 - Very first drag-copy of a JTable Selection causes the Selection to grow
Duplicate :  
JDK-4719702 - DND of text in JTextArea causes the disappearance of the text
Duplicate :  
JDK-4760465 - JTable setDragEnabled first time activated fails
Relates :  
JDK-4333906 - DnD object dropped is not the object removed
Relates :  
JDK-4710511 - Unexpected mouseRelease event received after calling exportAsDrag()
Relates :  
JDK-4752810 - REGRESSION: Regtest-test bug .../DelayedClassLoadingTest.sh fails on JDK1.4.2-b0
Description
Attached is a Zip file for the test case and following is procedure to reproduce a failure being encountered by our Test suite SwingDnD .

OS - Win 98 SE , Build 89 (Also on Build 83)

1. Unzip the file attached.
2. At Command prompt give : java -classpath .;ltf.jar;awtsqe.jar
InterJVMDnDTest
3. Two frames (Different JVMs) shall come up . When text is selected in
one frame and dragged the selection itself changes to more characters
than already selected . (Although the right characters get dropped to
the second frame )
4. If you issue the following command java -classpath .;ltf.jar
InterJVMDnDTest ,Robot shall not come up and you can try the same thing
on your own manually (i.e. Selecting Dragging and dropping ). Strange
also is the fact that this happens just the first time .On second trial
with a few other characters the failure does not happen .
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mantis mantis-b02 FIXED IN: mantis mantis-b02 INTEGRATED IN: mantis mantis-b02 VERIFIED IN: mantis
14-06-2004
PUBLIC COMMENTS .
10-06-2004
SUGGESTED FIX Name: dsR10078 Date: 07/30/2002 We cannot ignore all input events during drag and drop, since it will break existing applications that expect user input on drop (for example, show a modal dialog so that the user can accept or reject the drop). The suggested solution is to filter out all mouse events that are on the java event queue when startDrag is called. ###@###.### 2002-07-30 ====================================================================== Name: dsR10078 Date: 08/05/2002 With the current Java DnD implementation on Windows SunDragSourceContextPeer.startDrag(Transferable, long[], Map) may return before the native DnD subsystem gains control. This way mouse events still can appear on the event queue after startDrag is called and will not be filtered out by the original fix. Additional change is to modify the Windows implementation of Java DnD to guarantee that no mouse messages can be retrieved from the native message queue after SunDSCP.startDrag() but before the native DnD subsystem gains control. With this change WDSCP.doDragDrop() no longer blocks until the dnd operation completes, so there is no need to start a new thread to call WDSCP.doDragDrop() and this thread is eliminated. ###@###.### 2002-08-05 ======================================================================
05-08-2002
EVALUATION Fixing this in Swing would involve extensive changes to the Swing drag and drop code. I beleive this can be better handled in AWT drag and drop. Here is what is happening. Swing makes the assumption that once a drag and drop operation is initiated that no more mouse events will be delivered. This is (almost) consistent with the current AWT drag and drop implementation. However, there are some problems. 1) The DnD specification specifies that it is an implementation detail whether or not mouse events are delivered during a DnD operation. First, I think this spec should be changed to specify that "NO" events are delivered during DnD. It would be very difficult to handle DnD properly in Swing (or anywhere) if we had to figure out a way to ignore events that are delivered during DnD. 2) Although the current implemenation is almost perfect for Swing, there is one problem. Consider the following sequence of mouse events (where P represents a press and D represents a drag) made by a user. P1 D1 D2 D3 D4 D5 D6 D7 D8...... We capture these mouse events from the native system and dump them on the event dispatch thread. Let's say that at D4, we initiate a drag and drop. At this point, we no longer capture native mouse events and put them on the event dispatch thread. However, there often exists some events that have already been captured onto the dispatch thread and are waiting to be delivered. So really, although our implementation trys not to deliver events during DnD, a few are still delivered. I strongly beleive that the fix to all of this is two-fold. 1) Beef up the spec to say that no events will be delivered to components during drag and drop. 2) Purge any pending mouse events from the event dispatch thread once DnD has been initiated. Re-assigning to Drag and Drop. ###@###.### 2002-04-10
10-04-2002