CODEWITHSUNDEEP
javaswingwindows-10assertj
Stephen M -on strike-
Stephen M -on strike-

Reputation: 1077

AssertJ Swing not working on one Windows 10 machine

We are using the Robot in AssertJ Swing in a Demo version of our Java Application to perform some automated configuration changes to our application. This is much better and easier than teaching our salesman to do these things correctly.

The code is working for us on several Linux machines, a Mac and one Windows 10 machine. However, it is not working on our salesman's Windows 10 machine. His machine has Java 1.8 and we have run successfully under that version of Java on the other machines.

I've spent some time debugging the problem and haven't been able to resolve it. Here is the code that uses the Robot:

        FrameFixture fullScreenFrame = robot.getFullScreenFrameFixture();
        // Go to the configuration screen
        robot.runCommand("MENU config");
        robot.waitForIdle();

        // Select Buttons tab
        JTabbedPaneFixture tabbedPane = fullScreenFrame.tabbedPane();
        LOG.log(Level.WARNING, "Found the Tab Pane "+tabbedPane);
        tabbedPane.selectTab("Buttons");
        LOG.log(Level.WARNING, "Found the Buttons Tab");
        robot.waitForIdle();
        // Select the "or" button group
        robot.clickOnTable(fullScreenFrame, "buttons", "buttongroups", "Name", "or");
        robot.waitForIdle();

Here is the method that gets the fixture:

public FrameFixture getFullScreenFrameFixture() {
    return new FrameFixture(ROBOT, DataSource.getInstance().getFullScreenFrame());
}

DataSource.getInstance().getFullScreenFrame() returns the top level JFrame. The ROBOT variable is:

public static final Robot ROBOT = BasicRobot.robotWithCurrentAwtHierarchy();

The method robot.runCommand(...) doesn't even use the robot and looks like this:

public void runCommand(final String command) {
    try {
        SwingUtilities.invokeAndWait(new Runnable() {
            @Override
            public void run() {
                DataSource.getInstance().getFullScreenFrame().handleCommand(command);
            }
        });
    } catch (InterruptedException ex) {
        Logger.getLogger("com.hcs.orc.demo.DemoRobot").log(Level.SEVERE, "Bad news - Robot failed to run the command "+command, ex);
    } catch (InvocationTargetException ex) {
        Logger.getLogger("com.hcs.orc.demo.DemoRobot").log(Level.SEVERE, "Bad news - Robot failed to run the command "+command, ex);
    }
    waitForIdle();
}

This code is working correctly (and ties into our larger application) and brings up the configuration screen for our application.

Here is the wait for idle method:

/**
 * Wait for the Event Thread to be idle.
 */
public void waitForIdle() {
    ROBOT.waitForIdle();
}

The clickOnTable() method fails on the Windows 10 machine, because the the tabbedPane.selectTab("Buttons") method didn't actually click on the tab, so the table we are looking for isn't present on the screen.

Oddly, the selectTab() method thinks it did the right thing and so doesn't throw any errors. However, when I watch it, the mouse goes to the top of the screen above the tab and so clicks (if it clicks at all - I'm not sure) on the application title bar. Very strange, especially since it works on all the other systems (including Windows 10) that we've tried.

Here are some things I've looked at as possible problems on the failing machine and come up empty:

So, I'm looking for what I might have missed that is interfering with AssertJ Swing. Any suggestions or ideas?

Update 1

Tried different versions and bitness of Java on both the failing laptop and a working Windows 10 machine. Made no difference on either.

The failing laptop is running Windows 10 v1803. The working machine is running Windows 10 v1809.

We don't see an easy way to upgrade or downgrade Windows 10 to a specific version and don't want to join the beta testing for a salesman's laptop by upgrading to v1903.

Update 2

We selected the tab a different way (using regular Swing code, instead of AssertJ Swing code) and that, of course, worked. However, the next bit of AssertJ Swing code that needed to move the mouse, moved it to a different wrong location.

Looks like it is somehow doing the math wrong and clicking too high and too far to the left, even though Swing is feeding it the right coordinates (according to some of our added log statements).

Update 3

We tried it on a different laptop that is the same hardware and OS and it failed in the same way there.

Upvotes: 3

Views: 604

Answers (1)

Stephen M -on strike-
Stephen M -on strike-

Reputation: 1077

It is a bug in Java 8 that is documented here:

https://bugs.openjdk.java.net/browse/JDK-8196030?attachmentOrder=des

Unfortunately, the first comment from Oracle claims that the bug doesn't affect Java 8. This is not true as the test cases in the ticket fail on my test system that exhibits the problem.

I reported the problem to Oracle, but confidence is low that a fix for Java 8 will be forth coming.

I found that it does work correctly under Java 11.0.4 (supposed to be fixed in Java 11.0.1), so we are avoiding the problem by moving to Java 11 (which comes with its own set of problems).

Upvotes: 2

Related Questions