Question

DEX Agent - {CLICK} operation fails but X click operation works

  • 6 December 2023
  • 7 replies
  • 178 views

Userlevel 2
Badge

Hi,

At some point tests started to fail to execute {CLICK} operation on DEX Agent but they pass in local machine runs. 

Also, if I replace the {CLICK} operation with X click operation, the click works and the test passes on that same Agent.

Did somebody have a similar experience or maybe someone has an idea what can cause that?

We know that {Click} is using mouse movements Click operations (tricentis.com)

Following thigs are already tested:

  1. Agent process restart on DEX agent - didn’t help.
  2. Tricentic RDC service restart on Agent - didn’t help.
  3. Tricentis browser extension reinstall on Agent - didn’t help.
  4. Running the same test on the Agent with user’s opened RDP connection and running it through the ToscaCommander - test passes in this case on Agent.

So it looks like the issue only exists when the DEX is running a test on Agent.


7 replies

Userlevel 2
Badge

As a best practice you should be using x/X over {Click} anyway, as long as X works for the controls you are steering. (Cases like this are one example why.)

When you say the operation fails, what exactly happens? If the step actually fails, what is the error message in the execution log? Or is the step passing but the control doesn’t behave as though it was actually clicked?

Userlevel 2
Badge +1

As a best practice you should be using x/X over {Click} anyway, as long as X works for the controls you are steering. (Cases like this are one example why.)

Why should x/X be best practice when {CLICK} is clearly more readable? I would always consider the more readable option to be best practice. 

Userlevel 2
Badge +1

Hi,

We know that {Click} is using mouse movements Click operations (tricentis.com)

If you want mouse movement then you should use the Steering Parameter “UserSimulation” to to true. Or set it to false if you don’t. Using X or {CLICK} should not make a difference.

What kind of Widget do you click on? Note that for checkboxes you can also use “true” and “false” to set a desired state.

Userlevel 2
Badge

As a best practice you should be using x/X over {Click} anyway, as long as X works for the controls you are steering. (Cases like this are one example why.)

Why should x/X be best practice when {CLICK} is clearly more readable? I would always consider the more readable option to be best practice. 

Because they don’t behave in the same way:

  • x/X performs a .click() method on the object (for HTML, and similar equivalent for other engines like .Net and Java). It has no dependency on screen coordinates, it first checks whether the control is enabled & steerable, etc.
  • {Click} uses mouse simulation. It is dependent on screen coordinates (which can be foiled when other controls are overlaid on top etc), doesn’t know or care whether the control is actually enabled, etc.

Basically, x is the more stable option for automation overall.
Also worth noting that for HTML/web specifically, controls such as text boxes or GenericGUI elements which don’t support x/X as a click or treat it as a text value, you can use {Invoke[Click]} instead.

Userlevel 2
Badge +1

As a best practice you should be using x/X over {Click} anyway, as long as X works for the controls you are steering. (Cases like this are one example why.)

Why should x/X be best practice when {CLICK} is clearly more readable? I would always consider the more readable option to be best practice. 

Because they don’t behave in the same way:

I just tried that out. With both X and {CLICK} I could clearly see the mouse move towards the <A> link when UserSimulation is set to True. Only when UserSimulation is set to False I noticed a difference. Another hidden feature to look out for.

Basically, x is the more stable option for automation overall.

I disagree here. I much prefer the actual mouse movement and proper click and I use the UserSimulation steering parameter quite often to make sure of that. With all the JavaScript we have running in the background having a real click is far more reliable for us the just calling the click() method.

Calling click() on objects which are not visible or disabled sounds like a hack to me. Still, might be useful at times.

Userlevel 2
Badge

When you say the operation fails, what exactly happens? If the step actually fails, what is the error message in the execution log? Or is the step passing but the control doesn’t behave as though it was actually clicked?

 

The step was showing green in Execution log, the next test-step was failing with an error, but just because the click was passing without any change on screen. The {Click} step itself was not failing but was doing nothing, sorry for not making this important part clear from the very beginning.

 

However, I couldn’t keep the agent in that state for a long time for investigation, so I did the last thing which I was trying to avoid most, I restarted the Agent machine and the issue was gone, the test started to pass with having the {Click} test-step.

 

I don’t know what was the issue with DEX RDP connection, why the Agent was not allowing DEX’s RDP connection to perform mouse movements, however, now I can’t continue to investigate it.

From that experience I learned the issue:

  • was not on DEX service side - as I didn’t touch it, I just checked all configurations.
  • was not in the test itself - as the same test was running before and after the issue,
  • was not in RDP connection on Agent - because with user’s RDP connection and through the Scratchbook execution the same test was passing on that same Agent.

Probably there was some service on Agent which if I restart would solve the issue, but that I left for the next time.

Thank you for your thoughts, ideas and support. 

Userlevel 2
Badge

As a best practice you should be using x/X over {Click} anyway, as long as X works for the controls you are steering. (Cases like this are one example why.)

Why should x/X be best practice when {CLICK} is clearly more readable? I would always consider the more readable option to be best practice. 

Because they don’t behave in the same way:

I just tried that out. With both X and {CLICK} I could clearly see the mouse move towards the <A> link when UserSimulation is set to True. Only when UserSimulation is set to False I noticed a difference. Another hidden feature to look out for.

I wouldn’t say that’s a hidden feature - that’s just what UserSimulation is supposed to do.

Basically, x is the more stable option for automation overall.

I disagree here. I much prefer the actual mouse movement and proper click and I use the UserSimulation steering parameter quite often to make sure of that. With all the JavaScript we have running in the background having a real click is far more reliable for us the just calling the click() method.

Calling click() on objects which are not visible or disabled sounds like a hack to me. Still, might be useful at times.

The only one that can click on a disabled object is {Click}, because all it cares about is screen coordinates. I don’t think x works on invisible objects either.

Reply