Skip to content
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 13 additions & 3 deletions test/jdk/javax/swing/JFileChooser/bug4759934.java
Original file line number Diff line number Diff line change
Expand Up @@ -31,10 +31,11 @@
* @run main bug4759934
*/

import java.awt.Component;
import java.awt.Container;
import java.awt.Dialog;
import java.awt.Point;
import java.awt.Robot;
import java.awt.event.KeyEvent;
import java.awt.event.MouseEvent;
import javax.swing.JButton;
import javax.swing.JDialog;
Expand Down Expand Up @@ -72,8 +73,10 @@ public static void main(String[] args) throws Exception {
robot.mouseRelease(MouseEvent.BUTTON1_DOWN_MASK);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#27944 (comment)

All the clicks above are to click a button… Should we replace these clicks with programmatic clicks?

This is more reliable and quicker than robot.

The only possible issue is to to ensure the updated test still reproduces the original bug.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just noticed your comment: #27944 (comment)

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I referred to the original JBS issue for which this test was created - 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);

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

@honkar-jdk honkar-jdk Nov 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe the test hangs after - dialogBtn.doClick() and does not proceed to the test condition check. I'll need to check in depth as to why this is happening.

I see… It may be not worth the effort then.

I can create a separate JBS issue to look into it and as for the test changes use the doClick() for just the JFC's Cancel button. Does this sound good to you?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this sound good to you?

This is likely the best approach.

It's a new problem that we discovered. It doesn't prevent integrating the change to search for the Cancel button in the file chooser, yet it would be good to investigate what goes wrong when all the buttons are clicked programmatically instead of using the robot to generate mouse clicks.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Created a new JBS to track the doClick() issue - JDK-8371728

robot.delay(500);

robot.keyPress(KeyEvent.VK_ESCAPE);
robot.keyRelease(KeyEvent.VK_ESCAPE);
SwingUtilities.invokeAndWait(() -> {
JButton cancelBtn = findCancelButton(jfc);
cancelBtn.doClick();
});
robot.delay(500);

SwingUtilities.invokeAndWait(() -> {
Expand Down Expand Up @@ -121,4 +124,11 @@ private static void createDialog() {
dlg.setLocation(fr.getX() + fr.getWidth() + 10, fr.getY());
dlg.setVisible(true);
}

private static JButton findCancelButton(final Container container) {
Component result = Util.findComponent(container,
c -> c instanceof JButton button
&& "Cancel".equals(button.getText()));
return (JButton) result;
}
}