FxRobot.drag not working with Java10?

[ThomasDaheim]

Expected Behavior

Drag node under point to new position. This is how it worked previously.

Actual Behavior

No dragging started

Specifications

• Version: 4.0.15-alpha
• Platform: Win10, JDK 10, 64bit (10.0.2)

I have a test harness (for https://github.com/ThomasDaheim/ownNoteEditor) that worked fine before upgrading to Java 10. Now it stops working when trying to execute

FxRobot dragNote = drag(p2d, MouseButton.PRIMARY);
dragNote.drag(centerX, centerY);
dragNote.drop();

With p2d a Point2D and centerX, centerY double coordinates.

Previous actions like clickOn, moveBy, rightClickOn, push, doubleClickOn work as expected.

Any ideas where I could start looking?

Thanks, Thomas

[brcolow]

I would maybe perhaps try to use git bisect to find the offending commit, if any. Also check what are the DPI settings of the display. Would it be possible for you to try Java 11? Not sure of any issues that could possibly make just drag not work, this is the first I have heard of any issues with drag/drop specifically.

[ThomasDaheim]

Thanks, will have a look at your suggestions and report back.

Is there e.g. also any detailed logging I could switch on to gain more insights?

[brcolow]

Yes, you can add a third argument to verifyThat like so:

verifyThat(someBoolean, is(true), informedErrorMessage(fxRobot));

Take a look, for example, here:

https://github.com/TestFX/TestFX/blob/master/subprojects/testfx-core/src/test/java/org/testfx/cases/integration/MenuBarTest.java#L116

[ThomasDaheim]

After a longer fight with Netbeans, Gradle and JavaFX11 I have managed to get things running. Unfortunately, the result is the same:

• drag seems to be starting (mouse moves a tiny bit in the right direction)
• dag doesn't complete

Is there any way to get more output from the drag in order to see what happens behind the scene?

[brcolow]

Do you mean more output/information than what is provided by org.testfx.util.DebugUtils.informedErrorMessage? It's pretty verbose. If so - no - I don't think so. Perhaps it would be possible to add additional debugging specifically for drags to DebugUtils. However DebugUtils.informedErrorMessage should already be printing literally every type of mouse event/movement.

[ThomasDaheim]

Unfortunately, the verifyThat is never reached since the drag() hangs and doesn't complete.

Thats why I was looking for some kind of internal debug output to provide here.

[brcolow]

Ah, right. That makes DebugUtils not usable in this case. I wish I could provide more help or insight.

[htmoia]

I am getting the same exact behavior using

• The current master branch
• Windows 10 Pro (1803)
• OpenJDK 11.0.1

while launching tests from the IDE (IntelliJ): the drop() is never being completed. This can be reproduced by running org.testfx.cases.integration.DragAndDropTest#should_drag_and_drop_from_left_to_right which will never be completed due to the freezing drop() method. However, when moving the mouse the mouse moves to the target and the drop() will complete such that the test passes.

The reason must be somewhere within org.testfx.robot.impl.MoveRobotImpl#moveTo which is being called by DragRobotImpl#drop. and which will not get completed.

[htmoia]

The issue seems to be related to the RobotAdapter used. Running the tests with the AWT robot using -Dtestfx.robot=awt the tests pass seamlessly.

Thus, the Glas Robot seems to have a problem. Digging deeper the main issue lies within the WinRobot and especially the _mouseMove method which is not being completed. There might already be a bug report for this but the OpenJDK is under maintenance right now.

Staying tuned to it...

[ChrisLMerrill]

I am seeing a similar problem under JDK 12. Unfortunately, using the AWS robot doesn't help. If I change the target component to use startFullDrag() instead of startDragAndDrop(), it works. The unit test then fails, of course, since the component now can't copy into the dragboard. But this makes it very similar to #33 , which was fixed long ago and the unit test for it is still there (and passing, I assume).