Bug report: Simulate Click in Java programs doesn't finish if a modal window is shown

When using Simulate Click with Java-programs, UiPath Studio times out after clicking on a button that shows a modal window, unless you close the modal window manually.

I have created a demo to demonstrate the bug. The process is to click a button to show the window and then click OK to close the window. Clicking on the button that shows a regular window works fine but clicking on the button that shows a modal window results in a timeout and a “Click generic error”.


Current behavior: UiPath Studio clicks the button and wait until the modal window is closed or the timeout is reached.

Expected behavior: UiPath Studio should consider the click as successful and not wait for the modal window to close.

Workarounds: switching to Hardware Events or using Parallell activity.

To recreate the bug:

  1. Run the java program (you will need the Java runtime):
    java -jar DialogTest.jar

  2. Run the SimulateClickTestInJava workflow.

SimulateClickTestInJava.zip (12.8 KB)

Hi @ptrobot , here is a similar thread with the solution. Java App - Click Activity Ignores Timeout Setting and Produces Generic Error

That’s not a bug, that’s expected behavior of any application when there is a modal dialog. Modal dialog literally means you can’t do anything else until you clear the dialog. If you need to wait until the dialog disappears you can use Check App State for that.

Thanks for the reply! So UiPath doesn’t consider this a bug?

I don’t agree. A modal dialog box is for preventing the user from interacting with the main window. It shouldn’t however prevent UiPath from considering the click as done.

An example where simulate click works as it should (Notepad, not a java program).

The dialog box “Do you want to save changes …” is a modal window:


And the following workflow works fine because UiPath doesn’t wait until the modal window is closed:

It has to wait for the modal dialog to close or the next UI interaction will fail.

No it doesn’t which clearly the Notepad example demonstrates. Now if Notepad was written i Java, UiPath would have failed at the Click ‘Close’ step.

If the click close fails that has nothing to do with the modal dialog because it hasn’t gotten there yet, that’s because you’re using the wrong mode, a mode not supported by the application. As you said, hardware events works. So use that.

The click doesn’t actually fails. The click is performed and the modal window is shown. The issue is that UiPath doesn’t consider it a successful click, thus leading to a timeout and an error. This is the bug I want to report. For now I have used the workaround but it would be nice we didn’t have to resort it.

It’s common and normal for some modes to work and others not. Use the one that works, it’s not a workaround it’s just what your Java app supports.

It depends. Click with Simulate uses native Click APIs that Java objects expose. When a click is done on a modal window, that window opens and blocks the thread, thus blocking the response from the Java application to the Robot and causing a Timeout. If the window would close (in any manner), the thread would continue its execution. The workaround provided is used to make the click on a new thread in the Java app and avoids waiting for an answer.

To answer whether it is or not a bug, I would say that it isn’t, because in a sync manner, one would like to know if the Click with Simulate was executed successfully or not, so the Robot should wait for the answer.

However, we should expose the async flag in a better way.

1 Like

Ok, thanks for the explanation! This means that Simulate Click in Java programs that results in a modal window is more or less useless since the robot will be waiting for answer that will never come. Since the workaround with UseNonBlockingInput doesn’t wait for an answer, is there any added benefit to use it instead of Hardware Events?

Hardware Events method relies on the element location on the screen to know where to click. Therefore, Simulate still remains the only method for any kind of scenario when the app can’t be on the screen (the app is minimized, the app is covered by other apps, unattended, etc).

1 Like

This is not correct. I use Hardware all the time for unattended automations. And if the app is minimized or covered by another app, that’s what the Activate property is for.

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.