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`: > > Log of the `DragSourceMotionListenerTest.java` failure > ``` > ------- > 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 > ``` > > 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. > > Log of the `DragSourceMotionListenerTest.java` failure with only one > `waitForIdle` > ```text ... 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. ``` > 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 Ctrl, 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 Ctrl. Since this test fails, a real app may fail > to register the drop at the correct coordinates. Sounds right to me. Thanks for the investigation though. I did some stabilization to fix the failure, never tried to look into product issue for this one. Thought it might be another case of making the test stable. Then I'll drop this PR since this one might be a product issue too, needs further investigation. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27283#issuecomment-3409130503
