On Mon, 22 Sep 2025 04:02:52 GMT, Tejesh R <[email protected]> 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
