Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 481357

Summary: NPE in logo example on shift-drag
Product: [Tools] GEF Reporter: Frank Benoit <frank.rene.benoit>
Component: GEF MVCAssignee: gef-inbox <gef-inbox>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: matthias.wienand, nyssen
Version: unspecified   
Target Milestone: 4.0.0 / 3.11.0 (Neon) M4   
Hardware: PC   
OS: Windows 7   
Whiteboard:

Description Frank Benoit CLA 2015-11-03 16:41:30 EST
When dragging any element of the example, holding the shift key at the same time, the element is cloned.
While dragging a whole bunch of NPEs is generated:

Exception in thread "JavaFX Application Thread" java.lang.NullPointerException
	at org.eclipse.gef4.mvc.policies.AbstractPolicy.restoreRefreshVisuals(AbstractPolicy.java:88)
	at org.eclipse.gef4.mvc.fx.policies.FXTranslateSelectedOnDragPolicy.release(FXTranslateSelectedOnDragPolicy.java:117)
	at org.eclipse.gef4.mvc.examples.logo.policies.FXCloneRelocateOnDragPolicy.release(FXCloneRelocateOnDragPolicy.java:159)
	at org.eclipse.gef4.mvc.fx.tools.FXClickDragTool$1.release(FXClickDragTool.java:225)
	at org.eclipse.gef4.fx.gestures.AbstractFXMouseDragGesture.onMouseEvent(AbstractFXMouseDragGesture.java:133)
	at org.eclipse.gef4.fx.gestures.AbstractFXMouseDragGesture$2.handle(AbstractFXMouseDragGesture.java:56)
	at org.eclipse.gef4.fx.gestures.AbstractFXMouseDragGesture$2.handle(AbstractFXMouseDragGesture.java:1)

This repeats.
This was seen with commit f4faa7de7c1f3ebce32258bf1a15ee1ef4e20c0d 3-Nov-2015.
Comment 1 Alexander Nyßen CLA 2015-11-04 04:55:45 EST
I can reproduce this with the current HEAD revision.
Comment 2 Matthias Wienand CLA 2015-11-26 10:21:51 EST
The NPE originates from a selection change in-between the #press(), #drag(), and #release() calls within the FXTranslateSelectedOnDragPolicy. Within #press() an initialization is performed for each target part. The information that is saved for the target parts is then later evaluated within #drag() and #release(). However, if the selection changes in-between (due to cloning of the host part), the translation is not correctly initialized for the new target parts.

To resolve the issue, cloning could be implemented via a CloneOnClickPolicy that exclusively selects the clone. As dragging is processed after clicking, the clone's *OnDrag policies would receive #press(), #drag(), and #release() while the original host would not receive any of these events.

Additionally, we should consider implementing a generic mechanism to determine and save the target parts for all interaction policies. This could be done in the context of bug #481810.
Comment 3 Matthias Wienand CLA 2015-11-27 05:23:27 EST
I ensured that cloning solely selects the cloned content part instead of appending it to the current selection. Moreover, I combined the FXFocusAndSelectOnClickPolicy and the FXCloneOnClickPolicy to one FXCloneOrFocusAndSelectOnClickPolicy, so that either cloning or focusing and selecting is performed on click, but not both. Furthermore, I ensured that content anchorages are only detached/attached if necessary to prevent an exception when cloning a connection.

The code is published on the master branch. Therefore, I resolve this ticket as fixed for 3.11.0M4.