Very slow object recognition when using longer or gapped XPaths

[JonasBeiTXS]

We are experiencing very long object recognition times when using XPaths that contain "gaps".

Previously we used something like this:

FlaUILibrary.Click    identifier=//Button[@Name="loadingButton"]

Object recognition was pretty much instant.

But now we sometimes have the same loading button on screen multiple times. Therefore we need to differentiate and reference a unique parent container. This is our current solution:

FlaUILibrary.Click    identifier=//Pane[@AutomationId="leftPane"]//Button[@Name="loadingButton"]

In this case leftPane is the closest reliably identifiable parent element. The object tree would look something like this:

When using these longer XPaths, load times are about 30s per button, which seems excessive.

This is just one example. We have many other cases, where using the end of an XPath is very fast, but incorporating parent elements slows down object recognition considerably.

Is this known behavior? Can we do anything to speed up object recognition (on the automation side of things)?

Filling the "gap" like this did not yield any noticable improvements:

FlaUILibrary.Click    identifier=//Pane[@AutomationId="leftPane"]/Pane/Pane/ToolBar/Button[@Name="loadingButton"]

[Nepitwin]

Currently roboframework-flaui use always from desktop find first by xpath usage

• https://github.com/GDATASoftwareAG/robotframework-flaui/blob/main/src/FlaUILibrary/flaui/module/element.py#L225

Flaui supports additonal search patterns which could be potential an improvement for a better xpath element search

• https://github.com/FlaUI/FlaUI/blob/master/src/FlaUI.Core/AutomationElements/AutomationElement.Find.cs

The possibility to use them should be implemented in future scope.

Asweel flaui supports caching from elements

https://github.com/FlaUI/FlaUI/wiki/Caching

This can be used to store all found elements from cache. So only first search would be take a long time afterwards all keywords should be improved.

So this automatic caching feature must be implemented into robotframework-flaui.

${caching_id}  Cache Element        identifier=//Pane[@AutomationId="leftPane"]/Pane/Pane/ToolBar
FlaUILibrary.Click    identifier=/Button[@Name="loadingButton"]  caching_id=${caching_id}

I think caching has to be designed as keyword as main element which will be used afterwards to the search pattern.

[noubar]

Such manual caching for every xpath individualy is very time consuming to write the test cases.

Even this suggestion will not solve the performance issue @JonasBeiTXS is facing. Because his highest reliable window is not the main window of an one app existing in the ui tree. This means to find the corresponding reliable element will take time for caching too. Because it will go deep in every app found in the ui tree. Maybe caching helps for several clicks but after some update it is needed to recache otherwise will crash it will retake a long time again.

The only reason it is taking more than 30 second is that you have relatively crowded ui tree. Try to minimize windows number while you are testing. Look into this conversation #82 to see some wildcards available like contains or starts-with. To limit the xpath as much as possible.
If you cannot limit the amount of available windows.

Best possible xpath would be using

/Mainwindow[Someconstraint]//Pane[@AutomationId="leftPane"]/Pane/Pane/ToolBar/Button[@name="loadingButton"]

rather than

//Pane[@AutomationId="leftPane"]/Pane/Pane/ToolBar/Button[@name="loadingButton"]

[JonasBeiTXS]

Thanks for the quick responses. @noubar's suggestion greatly improved our execution time.

Adding /Mainwindow[...]// to every critical XPath did the trick. It's not very intuitive, as our SUT is usually the only application that is running. But it works.