On Tue, 7 Nov 2023 09:10:02 GMT, songpv-imt <d...@openjdk.org> wrote:
>> The root cause of the bug is because mousePress() method is invoked before >> mouseMove() event is completely processed causing the drag & drop behavior >> not being able to be recognized properly. This in turn makes the method >> dragSourceListener.isDropFinished() returns false and fail the test. To fix >> this, setAutoWaitForIdle(true) and Thread.Sleep is called to make sure the >> mouseMove() event is processed completely before moving to execute the >> mousePress() method. >> >> JBS issue: [JDK-8317287](https://bugs.openjdk.org/browse/JDK-8317287) > > songpv-imt has updated the pull request incrementally with one additional > commit since the last revision: > > Update InterJVMGetDropSuccessTest.java > Based on description in Chapter "17.4 Memory Model", and specifically > chapter "17.4.5 Happens-before Order" of the "The Java® Language > Specification", DragSourceDropListener.finished field is accessed from two > threads without proper synchronization which may also be possible causing the > test to fail. Hence, putting code accessing to > DragSourceDropListener.finished into a proper synchronization code block. Subsequent to submitting a job to verifying this, I've no objection to stability fixes but from what I saw on macOS 14.0 this failed because of some macOS 14 event delivery changes which have been resolved in macOS 14.1 test/jdk/java/awt/dnd/InterJVMGetDropSuccessTest/InterJVMGetDropSuccessTest.java line 281: > 279: boolean success1 = false; > 280: synchronized (Util.SYNC_LOCK) { > 281: robot.mouseRelease(InputEvent.BUTTON1_MASK); In all uses in this file you can change this to BUTTON1_DOWN_MASK since BUTTON1_MASK is deprecated https://docs.oracle.com/en/java/javase/21/docs/api/java.desktop/java/awt/event/InputEvent.html#BUTTON1_MASK ------------- PR Review: https://git.openjdk.org/jdk/pull/16396#pullrequestreview-1718916499 PR Review Comment: https://git.openjdk.org/jdk/pull/16396#discussion_r1385676006
