AssertJ not clicking boxes - Java 11

[hirshbergshachar]

Summary

I’m not able to use basic click functionalities with AssertJ (basically everything related to activating buttons)

Opened a thread about it in STO as well -

I’m not sure if it’s a regression or if I’m just missing out something obvious… the example here - Example is not working on my env as well (Java 11)

Example

The GUI is a JPanel and I use Containers.showInFrame to display it.

The panel has some text fields, JCheckboxes and JComboboxes.

I'm able to set text in the text fields, but I am not able to check/select the boxes. Been breaking my head but couldn't figure out what is missing...

Working:

frame.textBox("example").setText(result).requireText(result);

Not working:

frame.checkBox("exampleCheckBox").uncheck().requireNotSelected(); 
frame.checkBox("example2CheckBox").check().requireSelected();
panel.comboBox("exampleComboBox").selectItem(2);

The component description that I get for a checkbox is:

[javax.swing.JCheckBox[name='exampleCheckBox', text='Mandatory', selected=true, enabled=true, visible=true, showing=true] - property:'selected']

Using Java 11, Gradle build, latest assertj-swing-junit and assertj-core.

Would highly appreciate any leads! Thank you

[hirshbergshachar]

Related to https://github.com/joel-costigliola/assertj-swing/issues/226. It seems that click functions don't work with Java 11. Regressed to Java 10 and everything is working fine

[croesch]

Hi @hirshbergshachar

Thanks for reporting this issue. Currently there is no advice but I also didn't have time to analyze the framework state against Java 11. Any help will be appreciated ;)

Since this is not the only issue open for Java 11, AssertJ Swing seems to be not ready for Java 11.

[croesch]

Can you give some information of your environment to find out the differences to #226

[hirshbergshachar]

Using MacOs Mojave, Java 11, Gradle 4.2 build, latest assertj-swing-junit 3.8.0 and assertj-core 2.9.1

[DaveBrad]

Seeing similar issues using JDK1.8.0_192. Sometimes works, more often does not work. Appears to be radio, tree selectpaths, OK buttons in popup dialogs. I've over a 1000's GUI interaction testcases which haven't run for awhile. Just trying out 30 TCs so far has shown major issues.

The issue appears to be the movement of the mouse to a point within the Button/radio/---. With radio button doing a focus() first and then the click(), resolved the issued. However, tried focus() on the OK button of a dialog, doesn't resolve.

This issue maybe one of:

1. Java has changed (OpenJDK) which isn't calculating boundaries correctly.
2. AssertJ-swing is not calculating correctly the center point for "click" actions.

I've changed the version of JDK used (back to JDK1.8.0_171) and still had the issue. So I'd suspect 2). But this maybe caused by assertj-swing being built against and old JDK and compatible to JDK 8 assumed. At one time I tripped across a JDK 8 change/update that stopped backward compatibility. But OpenJDK and Oracle JDK are unresponsive to issues and appear not to care (the bane of open-source).

[DaveBrad]

In follow up. Used the latest assertj-swing source code and compiled within a Netbeans 8.2 environment. thus, compiled against JDK1.8.0_192. Same issue persists.

However, observing the tests which have click, the mouse is consistently not on the object when the pressMouse happens. So tried debug, guest what, under debug with breakpoints no issues. Based on previous experience this tells me that a mouse-position/move is not completing prior to the pressMouse event. (assetj-swing code BasicRobot.java-> doClickWhileModifiersPressed)

`String selectionPathStr = "test1svn/cvs_testbed"; this.winFixT0.dirTreeF.selectPath(selectionPathStr);

above has consistent failure conditions, all but intermittent

String selectionPathStr = "test1svn/cvs_testbed";

// pre-position the mouse pointer this.winFixT0.robot().moveMouse(this.winFixT0.dirTreeF.target().getLocationOnScreen()); Thread.yield();

this.winFixT0.dirTreeF.selectPath(selectionPathStr);`

Pre-position the mouse on the component, and then Thread.yield(); works all the time.

This suggests that the position mouse for a click() does not complete correctly. This appears to be either:

1. change in JVM/JDK code, which implies dream-on to get it fixed 2a) AWT Robot has changed dispatches events too quickly (mmmmm, not sure) 2b) change in assertj-swing (AS) around positioning prior to clicks somehow affects the event-dispatch timing
2. things have been speeded up in JDK and AS which are causing a boundary timing issue.

Note: I run a MSI PE70 laptop with 1+2 monitor with Win10-home. IDE is Netbeans 8.2 and tests are using TestNG framework and run all tests sequentially.

In an attempt to isolate issue I've done the following (without the explicit moveMouse workaround:

• have disconnected +2 monitors, thus just the laptop monitor (still have issue)
• set processor speed, slow, medium and high (still have issue)
• disabled anti-virus (still have issues)
• installed AS source code and compiled against JDK1.8.0_192 (still have issue)
• run in debug mode: -- without breakpoints (still have issue) -- with breakpoints [BP] (ISSUE DOES NOT OCCUR) --- placed a single BP before the selectPath (no other BPs) [tired different positions in the code] --- placed a single BP after the selectPath (no other BPs) [tired different positions in the code]

In closing (for now):

• appears the mouse is not positioned correctly on the component by the time a pressMouse for the click is done

[DaveBrad]

Found a work-around for my stuff.

The issue is a moveMouse or mouse-location dependent Fixture action (eg. click()) is not positioned correctly for the actual click dispatch-event. Its as if the move_mouse/cursor/pointer is being dropped from the event list for AWT.Robot. I don't have the knowledge to go further.

Below is a work-around.

• Do double AWT.Robot moveMouse results in the mouse being positioned appropriately.

I'm unable to test for JDK 11 but with JDK1.8.0_192 this removed stupid failures nicely and my app testing works smoothly, other than expect graphic rendering difference between Win7 to Win10.

Code below approx line 113 AssertJ-swing-3.9.2

package org.assertj.swing.core; RobotEventGenerator ::: @Override public void moveMouse(int x, int y) { // TODO appears a regression has slipped into AWT.Robot moveMouse // a single moveMouse does not appear to position correctly, but // if followed by a 2nd seems to overcome the AWT.Robot issue. // // Root cause is not understood, but it like an event is dropped // for positioning the pointer robot.mouseMove(x, y); robot.mouseMove(x, y); }

[DaveBrad]

Decided to look for movemouse issues for AWT robot.

Appears there are a number of them (eg. https://bugs.openjdk.java.net/browse/JDK-8186063). So the problem is for Windows 10 OS and scaled screen which does not apply to OP'ers MacOS.

However, my Windows 10 environment is set at 100% scale, so should not have had this problem, but I did. The work around above [other comment] is an appropriate approach to the problem. And in my case resolves the issue. There are duplicates (https://bugs.openjdk.java.net/browse/JDK-8196030) which are a better description, and also point to JDK 7,8, 9, 10, 11 also having the problem, but on Windows 10.

I don't have MacOS access so unable to confirm. My Linux environment does not have this issue, and the work around does no harm. (Linux is virtualbox Opensuse XFCE).

Summary from reports Appears AWT.Robot moveMouse has issues with:

• scaled screens
• large screens (4K)
• seen a multiple monitor report problem, with similar concerns when using AWT.Robot (but not quiet the same)

Hopefully this is helpful.

[LorenzoBettini]

I'm experiencing testing failures in Windows 10 as well, while it works perfectly fine in Linux.

From my findings:

• when using scaling factor (e.g. 125%), tests are green when using JDK 11.0.2, while some of them fail with JDK 8. The mouse is not positioned correctly before the click in JDK 8 (e.g., for clicking a button or selecting an element in a list). Indeed, with JDK 8, the Swing application does not seem to apply the scaling factor itself (it's indeed smaller than the rest of the windows); while, with JDK 11.0.2 the Swing application seems to respect the scaling factor.
• when not using scaling factor (e.g., 100%), but, important, you have to logout and login again after switching to 100%, everything works fine also with JDK 8

Thus, it seems to work with JDK 11.0.2.

I don't know if my findings make sense in this bug or they are unrelated, but the symptoms look similar.

[DaveBrad]

I'd say the issue you are having is the same as I found on Win10. I rebuilt a special assertj-swing with the following method replaced for org.assertj.swing.core RobotEventGenerator.java

     public void moveMouse(int x, int y)  
       // TODO appears a regression has slipped into AWT.Robot moveMouse  
       // a single moveMouse does not appear to position correctly, but  
       // if followed by a 2nd seems to overcome the AWT.Robot issue.  
       //  
       // Root cause is not understood, but it like an event is dropped  
       // for positioning the pointer  
       robot.mouseMove(x, y);  
       robot.mouseMove(x, y);  
     }

You don't say which JDK 8 you are using. I've gone to AdoptOpenJDK jdk8u202-b08 (hotspot) but this has the mouseMove issue. I no longer use Oracle Java because JDK 11 has restricted license and is not general use.

I have 3 monitors, so the issue always shows even if scale is 100%.

[LorenzoBettini]

As specified here https://bugs.openjdk.java.net/browse/JDK-8196030 this has been fixed in jdk 11.0.1. All previous versions have this big from what I understand

[croesch]

@hirshbergshachar the original problem was like nothing works at all, right? Is this solved by the solution mentioned in #224 - which is a security restriction under MacOS.

@DaveBrad and @LorenzoBettini thanks for your comments - do your tests still fail? Always? Sometimes?

If sometimes, does the JDK update make any difference?

[LorenzoBettini]

In my case the tests (concerning clicking) almost always fail unless I remove the scaling or I update to JDK 11.0.2

[johnasherrayan]

is this solved? I am also having similar issue mouse clicking works only if i lower the resolution? is there a workaround so that mouse clicking can be performed with default resolution. @croesch

[DaveBrad]

is this solved? I am also having similar issue mouse clicking works only if i lower the resolution? is there a workaround so that mouse clicking can be performed with default resolution. @croesch

I've not seen any work being done on this. The root cause is Java 8 Robot and is likely not going to be fixed in Java code. I've not tried with JDK 11 yet.

I'd suggest you: 1) move to Java 11 or 2) build the AssertJ-swing with my suggested workaround above. It doesn't take long.

[jimpete]

As I'm relegated to a project stuck in Java 8 the best working solutions for me so far was:

1. LorenzoBettini suggestion to set the display scaling to 100%. I Confirmed this works.
2. DaveBrad suggestion to change the RobotEventGenerator to call moveMouse twice. I confirmed this worked with a scaling of 125% which had previously failed.

[billsdesk]

I wrote this to overcome the problem clicking on buttons and it works in Java 22.

   /**
     * Overcome bug in AssertJ where fixture.button(name).click(); does not work.
     *
     * @param fixture
     *            window fixture
     * @param name
     *            button name
     * @throws InvocationTargetException
     *             thrown error
     * @throws InterruptedException
     *             thrown error
     */
    @SuppressWarnings("rawtypes")
    public static void doClick(final AbstractWindowFixture fixture,
                               final String name) throws InvocationTargetException,
                                                  InterruptedException {
        SwingUtilities.invokeAndWait(new Runnable() {
            @Override
            public void run() {
                fixture.button(name)
                       .target()
                       .doClick();
            }
        });
    }