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]

Same issue here Edge Version 140.0.3485.54 in Blue Prism 6.10.1. Blue Prism is aware and is investigating, as Adrian mentioned and linked to.

[willem.d4s]

We're experiencing issues with UIA too.  I really hope that there is an official solution from BP soon.   For us it is affecting BP v6.10.5 and v7.3.1.   Unfortunately we are not able to roll back to Edge v139.

[Michael_S]

Hey all, just wanted to drop in and say our engineers are investigating. I don't have any new information for you right now, and the best (and fastest) source of current information on this will be the Known Issue which @Adrian__Dones linked:

https://support.blueprism.com/en/support/solutions/articles/7000095180-why-do-i-have-browser-automation-issues-after-updating-to-chrome-version-140-

If the team have any questions, or I get any other info, I'll post it here. 

EDIT: I have merged another post which discusses this issue into this one, just to keep everyone informed and the forum tidy 🙂

[james.keefe]

Same issue here, its caused some major havoc here. I can manually jig through stuck automations by wiggling the mouse/click/F5'ing hoping for the best but its not fun. The official answer of rolling back to earlier edge/chrome just isn't viable. 7.3.1 user

[david.l.morris]

As @james.keefe said, we're finding that we can get it to move forward by just moving the mouse around. In our case, we go into the Runtime Resource machine through vSphere and move the mouse around (sometimes have to click to get into the session so maybe the click is what does it sometimes), and then the stage becomes unstuck and moves forward. This seems to usually happens with wait stages (especially when an element is not found or when an element doesn't exist), but it also happens with navigate stages such as global mouse click.

I have been running tests all day in different scenarios for different automations, and I can't reliably reproduce the issue. I think a big reason for this is that the issue immediately goes away if you have clicked into the browser with a global click (whether manually or automatically). Because of this, you basically never see the issue in debug mode. I suspect it should actually be possible for it to happen in debug mode, but I haven't figure out how to make that happen yet.

[stepher]

Ours situation seems to be a mixed bag.  Some automations ran successfully, and then the same Process on the same machine would lock up.  In those instances, my Operations team were able to access the Runtime (via Bomgar) and it seemed to correct itself.

That said, once I had identified a specific action in an Object, my results were slightly different.  If I stepped "into" the action and let it run, it was fine.  If I stepped "over" the action, from the Process, it would lock up.  That part squares with what @david.l.morris said.  However, in this (many) instance, no amount of mouse activity got it to unstick.  My only 'resolution' was to close out the browser (MS Edge, in my case) and that allowed the Action/Object to wake up (and throw an exception).

Looks like we are rolling back to v139.x.  Should be fun.

Thanks,

Red

[sy_lee]

Hello.

I've been trying various methods over the past few days to fix an issue where Blue Prism 7.4.1 isn't working correctly with Microsoft Edge Build 140.

First, I want to let you know that I was unsuccessful in downgrading Edge.

During my work, I found that when I use the Highlight function in Application Modeller, it correctly identifies the element. However, when I run tests using Step Over, a "More than one..." message appears, and the test fails.

This error doesn't happen on every website, but I believe it's helpful information to share.

I confirmed that the process works correctly when I set the Match Index value for elements that don't have one specified.

Although this hasn't been verified for a wide range of cases, so it may not be a complete solution, it could be a way to handle the current problem.

I hope this helps with the issue you're facing.

[Ninoseki]

Hello @sy_lee, 

Thank you for sharing the information.

While reviewing the Chromium issue list—the core of many web browsers—I came across an interesting bug report related to UIAutomation. It appears to align with some of the details you provided, which makes this finding particularly relevant.
From Chrome 140+, multiple popup dialogs (e.g., Extension etc.) are detected via UI Automation tool [439716356] - Chromium

I hope this bug will be addressed and fixed in the near future, as it could have a meaningful impact on our work.

Best regards,
Yusuke Ninoeki

[sy_lee]

It seems this symptom is primarily found when UIA uses the *'Item' property.

[Anton__Hosang]

did you mean using the Wildcard attribute type?