Blue Prism UI Automation Failing after Chrome / Edge Update to 140

[Adrian__Dones]

Hi guys,

Hope all of you are well and have a great week start.

Starting from last week (around Wednesday~Thursday) Blue Prism fails while running to identify properly the fields spied using UI Automation mode.

While trying to check in Application Modeler if the fields can still be visible, they were successfully identified, but while running the whole process, somehow the process remains blocked while trying to access those fields.

The interesting part is that after re-spying the fields using UI-Automation (just to test if a new fresh set of fields would make the cut) the bot still fails.

Just to mention, the process worked properly without any errors more than 2 years and all of a sudden it failed to work anymore.

Please let me know if this is a general issue and/or how it can be fixed.

Much appreciated all your help 🙂

[david.l.morris]

@DeclanKeeton I came across an issue today where I found that the same element spied in UIA had different attribute values from one machine to another with the same Edge version and with both launching using the flag as a launch parameter.

I don't know if that's the same issue you're seeing or not, but what I did was figure out what both possibilities were and I configured a single element in app modeller with wildcards and/or regex matches so that it supported both.

For example, I found that one element on one machine could have a UIA Control Type of "Button" and another machine might have the same element with a UIA Control Type of "MenuItem". I changed the match type to Regex and set the value to "MenuItem|Button" which means "either MenuItem or Button". Something to consider when you're adjusting attributes then is to keep the same original attributes working properly and adjust to make it flexible enough to support the new attribute values at the same time. A second option there might be to just have 2 separate app modeller elements representing the same page element and two different paths in a wait stage. 

[Denis__Dennehy]

Great information David.

On Not being allowed to control MS Edge updates, difficult one.  It should never be for the RPA team to control it, but there should be a different group for the robots so that update is part of a governed change control - that is for the IT service team to engage and do,  they are adding additional operational risk by not doing that so it should be possible to get exec sponsorship to do it.

The one type of company where that is often not possible at all are BPO service providers, they usually get what they are given with little ability to change it - that incluces having to automate via citrix desktops etc.

[DeclanKeeton]

Hi David, 

That's brilliant information to know & gives us a consideration we hadn't considered. 

With the issue we have, we've noticed when Edge launches we never seem to get UIA class back when using UIA Provider Disabled. Using this info we're under the impression that it's not launching with UIA provider disabled. (we're not aware of a clearer way to test if the launch was successful)

So we're actually a little unstuck trying to understand why launching with --disable-features=UiaProvider is working at all our clients bar one. (We believe that it's a security setting but we're just unsure what & the trouble shooting has been placed at our feet)

[sastharpa]

This is not great as most production nodes failing, was it communicated officially?. However, The workaround suggested in @ Michael_S post heled.

[willem.d4s]

It might help to put some more pressure on the Chromium team.  If everyone clicks the ( + 1 ) button on the top right-ish of this page:

From Chrome 140+, multiple popup dialogs (e.g., Extension etc.) are detected via UI Automation tool [439716356] - Chromium

The +1 means: "I am also impacted".   You have to be logged in with a Google account to be able to click it. 

[siebrenmichiels]

I'm experiencing the same issues in Chrome. I tried the workaround with '--disable-features=UiaProvider', however, it doesn't seem to resolve the issue. Anyone else that had to change something else? 

Kind regards, 

Siebren

[Michael_S]

Hello everyone, I wanted to drop in and provide an update on what we understand about this issue so far.

The issue stems from Chromium (the codebase that powers both Edge and Chrome) introducing native UI Automation from v138 onwards, which replaces the emulated UI Automation layer that was previously used by Chromium browsers. In the latest version (140), this native UI Automation was turned on by default, and our understanding is that a bug in the native UIA is causing this issue.

The --disable-features=UiaProvider parameter disables the native UI Automation, reverting to the old mode, which is why it fixes the issue for some of you.

We've also noticed that some elements in the application modeller have different names or values, which is breaking existing application models. Whilst respying can help, we know it's not a practical solution for everyone due to the volume of items that would require rework. 

Our team are continuing to monitor information coming from browser vendors on the reported issues and we are attempting to contact both Chrome and Microsoft to offer additional information/insight to assist in identifying a resolution.

In the meantime, please refer to our own Known Issue article for the official information on workarounds: https://support.blueprism.com/en/support/solutions/articles/7000095180-why-do-i-have-browser-automation-issues-after-updating-to-chrome-version-140-

PS. As a small note from me - thank you for being kind and helpful towards each other, and for sharing what you're experiencing. It's been incredibly useful to us internally and to your fellow automators, I really appreciate it. 

[siebrenmichiels]

Nevermind, found the issue!