On Fri, 7 Nov 2025 19:10:47 GMT, Harshitha Onkar <[email protected]> wrote:
>> I just noticed your comment: >> https://github.com/openjdk/jdk/pull/27944#discussion_r2496343433 >> >>> I'm for keeping the other clicks as-is (via Robot) since we have reference >>> to these buttons unlike the cancel button of JFileChooser and this way keep >>> much of the original test case intact without overly modifying it. >> >> “…Since we have reference to these buttons,” it's even easier to call >> `frameBtn.doClick()` and `dlgBtnLoc.doClick()`. >> >> Once you get the reference to the Cancel button in the file chooser you can >> also use robot to click the button. >> >> Using consistently the same method to click the buttons makes the test >> easier to comprehend. > > I referred to the original JBS issue for which this test was created - > [JDK-4759934](https://bugs.openjdk.org/browse/JDK-4759934). Looks like we can > use doClick() instead of using Robot for the clicks. > > But the problem is that when we use doClick() for frameBtn and dialogBtn, > JFC's click on Cancel button doesn't happen and the test fails due to > timeout. This happens on macOS26, I have to test on other platforms. > > > > SwingUtilities.invokeAndWait(() -> frameBtn.doClick()); > robot.waitForIdle(); > robot.delay(500); > > SwingUtilities.invokeAndWait(() -> dialogBtn.doClick()); > robot.waitForIdle(); > robot.delay(500); > > SwingUtilities.invokeAndWait(() -> { > JButton cancelBtn = findCancelButton(jfc); > cancelBtn.doClick(); > }); > robot.delay(500); I see… It may be not worth the effort then. However, this behaviour — clicking the Cancel button doesn't happen — could be a bug. Why does the test time out? Even if clicking the Cancel button didn't work, the test should finish with a failure. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28169#discussion_r2505202670
