RFR: 8225131: Test DragSourceMotionListenerTest.java fails on Windows [v3]

[Alexey Ivanov]

On Mon, 22 Sep 2025 04:02:52 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Test is failing frequently on mach5 machines. I have fixed it with stabilizations and moved the frame to center of the screen. After the fix several runs were made on mach5 and no failures were seen.
>
> Tejesh R has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove blank space
>  - Revert indentations

What do we know about the test failure? Not much.

According to the bug report, the test fails with the message “Failed first test.” This message means that the test didn't receive `dragMouseMoved` event that lies outside of the frame bounds.

https://github.com/openjdk/jdk/blob/1d6cafdc5244960ddec2fd82b8454c6c3cafe022/test/jdk/java/awt/dnd/DragSourceMotionListenerTest.java#L90-L94

I added traces to different parts of the test, and this is what I found out. The test stops receiving mouse events via `dragMouseMoved`:

<details><summary><b>Log of the <code>DragSourceMotionListenerTest.java</code> failure</b></summary>


-------
 srcPoint : java.awt.Point[x=107,y=130]
testPoint1: java.awt.Point[x=621,y=118]
testPoint2: java.awt.Point[x=307,y=130]
-------
Start dragging to java.awt.Point[x=621,y=118]
    107, 130
    108, 129
    109, 128
gestureListener -> startDrag
    110, 127
java.awt.Point[x=111,y=126]
    111, 126
    112, 125
        dragMouseMoved: 113, 124
    113, 124
        dragMouseMoved: 114, 123
...
    227, 118
        dragMouseMoved: 228, 118
    228, 118
    229, 118
...
    620, 118
Drag started? true
Move down
    621, 119
...
    621, 128
To drop target: java.awt.Point[x=307,y=130]
    621, 128
    620, 129
    619, 130
...
    309, 130
    308, 130
Release mouse
dragDropEnd: 228, 118


</details>

Thus, the last time the `dragMouseMoved` method was called with coordinates of (228, 118). It's the mouse coordinates that are reported by `dragDropEnd`.

Indeed, adding `robot.waitForIdle()` after dragging the mouse to `dstOutsidePoint` helps resolve the missing mouse events. Why aren't mouse drag events delivered?

This looks to me like a product bug rather than a test bug. Watching the test running, robot doesn't move the mouse too quickly, a user is capable of moving mouse quicker. Will the drag operation fail if the user moves the mouse pointer too quickly?

Additionally, I was able to make the test fail with this additional `robot.waitForIdle()`. In this case, the mouse events get delivered so that `passedTest1` is set to `true`. Yet while the mouse is dragged to `dstInsidePoint`, the `dragMouseMoved` stops being called.

<details><summary><b>Log of the <code>DragSourceMotionListenerTest.java</code> failure with only one <code>waitForIdle</code></b></summary>

...
    622, 119
passed1: 623 ~ 624
         dragMouseMoved: 623, 119
    623, 119
Drag started? true
<-- waitForIdle
...
To drop target: java.awt.Point[x=308,y=131]
passed1: 624 ~ 624
         dragMouseMoved: 624, 129
    624, 129
...
    354, 131
         dragMouseMoved: 353, 131
    353, 131
    352, 131
    351, 131
...
    310, 131
    309, 131
Release mouse
dragDropEnd: 353, 131
----------System.err:(11/653)----------
java.lang.RuntimeException: Failed second test.


</details>

Again, the mouse coordinates in `dragDropEnd` are exactly the ones in the latest call to `dragMouseMoved`: (353, 131).

Adding another `robot.waitForIdle()` after drag is complete but before release the mouse button makes the test stable; at least it has never failed for me in this configuration.

But why are so many `waitForIdle`s needed?

The should be stable as it is written now. The robot simulates the user's behaviour: press <kbd>Ctrl</kbd>, press the left mouse button and start dragging… outside of the app window and return back to the app window, then finally release the mouse button and <kbd>Ctrl</kbd>. Since this test fails, a real app may fail to register the drop at the correct coordinates.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27283#issuecomment-3398999965