<AWT Dev> [8] Review request for 8024061: Exception thrown when drag and drop between two components is executed quickly

[Artem Ananiev]

Hi, Anton,

thanks for details description of the bug and suggested fix. It helped a 
lot.

My understanding is that the problem is not with step 2, but step 3. 
Generating "drag entered" events on mouse press looks incompatible, I 
can't predict side effects of such a change. Fixing step 3, so we don't 
assume drag entered events already sent, looks more correct. What do you 
think?

Thanks,

Artem

On 10/11/2013 7:49 PM, anton nashatyrev wrote:
> Hello,
>      could you please review the following fix:
>
> fix: http://cr.openjdk.java.net/~mcherkas/anton/8024061/webrev.00/
> <http://cr.openjdk.java.net/%7Emcherkas/anton/8024061/webrev.00/>
> bug: https://bugs.openjdk.java.net/browse/JDK-8024061
>
>      Problem:  when doing quick drag'n'drop in X11 the incorrect
> behavior appears in the different forms. One is the exception when
> trying to get 'local Jvm' Transferable from DropTargetListener.
>
>      Reason: on quick drag the following sequence of events may appear:
> (1) mouse pressed on source  -> (2) mouse moved to target in a single
> X11 event -> (3) mouse released. What's happening in that case: on event
> (2) only a drag gesture is recognized and no drag enter is generated
> yet. On event (3) the XDragSourceContextPeer assumes that entered event
> (if it happened) was already generated and the 'local JVM' transferable
> had been already captured by SunDropTargetContextPeer from the static
> field currentJVMLocalSourceTransferable. Thus on event (3) the
> XDragSourceContextPeer posts the additional mouseMove event (which turns
> into DragEnter later) and initiates the cleanup which then resets the
> currentJVMLocalSourceTransferable to null. Thus on DragEnter the
> currentJVMLocalSourceTransferable is already null and the
> SunDropTargetContextPeer appears in the inconsistent state.
>
>      Solution: the event (2) from the example above should not only
> initiate the DnD operation but also be a part of that operation, i.e.
> this event should also appear as a drag motion. For that I propose to
> keep a track of the XMotionEvents in the XDragSourceContextPeer to catch
> the mouse event which initiated the DnD and when a startDrag() is called
> process this event as the first drag motion event.
>
> Thanks!
> Anton.