RFR: 8165749: java.lang.RuntimeException: dndGesture.dragboard is null in dragDrop

Jose Pereda jpereda at openjdk.java.net
Wed Jan 6 17:42:55 UTC 2021

On Wed, 6 Jan 2021 17:05:09 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> As commented in the JBS issue, there is one single `dndGesture` object in `Scene`, that can be instantiated from three different ways: 
>> - DropTargetListener, on dragEnter 
>> - DragGestureListener, on dragGestureRecognized or 
>> - MouseHandler, processing a right mouse click (these two are mutually exclusive).  
>> This PR prevents that, for two almost simultaneous drag events (for instance via mouse and touchpad), the `dndGesture` for the last of these events gets initialized again, losing all existing drag info (`dndGesture.dragboard`) that was added to the first one, avoiding the RTE.
>> The existing manual test [DndTest](https://github.com/openjdk/jfx/blob/master/tests/manual/dnd/DndTest.java) has been used on MacOS to verify the PR.
> modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 3788:
>> 3786:                         //old gesture ended and new one started
>> 3787:                         gestureStarted = true;
>> 3788:                         if (!PLATFORM_DRAG_GESTURE_INITIATION && Scene.this.dndGesture == null) {
> This will prevent the creation of the new `DndGesture`, but we will still clear the PDR targets. Have you confirmed that this is the desired behavior? It seems reasonable, since we also clear it on a mouse move, but wanted to get your take on it.

This is really an edge case. There can be two gestures at once, an existing one (i.e from TouchPad), with its full drag information, that hasn't finished yet, and a new mouse one. 

Having a single `dndGesture` object for both events seems wrong. But having a list/array of events for such scenario seems overkill. 

Somehow some information from one or the other event might get lost or mixed up. The PDR targets are not required for the initial touch event, and we prevent the RTE, so I'd say this is a reasonable non-intrusive fix.


PR: https://git.openjdk.java.net/jfx/pull/372

More information about the openjfx-dev mailing list