As part of our existing Chrome-based web automations, the Input Method was originally implemented using Hardware Events. Over the past few days, we have been experiencing a significant increase in fallouts and instability.
During our analysis, we observed that switching the Input Method to Chromium API helps mitigate many of these issues. We would like to understand if others have encountered similar challenges in their automations.
Specifically, has anyone noticed a significant spike in “Unable to find element” errors in recent days when using Hardware Events?
Also from your experience, is the Chromium API generally more reliable and recommended for Chrome automations compared to Hardware Events? Are there any known best practices or considerations we should be aware of when making this transition?
General
Normally, we should avoid Hardware Events if possible. First, try using the Chromium API, then Simulate, and only use other methods if needed. The Chromium API is more reliable and recommended for Chrome/Edge automations.
We are also having this exact same issue. Friday automations were fine, Chrome update over the weekend, bunch of automations broken.
This is the second time this has happened in a month or so. The first time, a subsequent Chrome update resolved the issue. But we cannot afford to wait for Google to accidentally fix it.
Having to update a bunch of automations to switch to Chromium API, when they’ve worked fine the way they are for months or years, isn’t really acceptable - that’s a lot of wasted resources.
@loginerror this seems like a major issue that maybe UiPath needs to talk directly to Google/Chrome about.
It’s something to do with Hardware Events not properly recognizing the UI layers and not clicking in the correct spot.
Considering Hardware events is recommended as a ‘last resort’ type of thing when working in web browsers such as Chrome, if you decided to build all your automations on Chrome using hardware events I think thats an issue for you to take up rather than expect UiPath to complain to Google.
The only thing I’d say to be aware of with Chromium API is that these days it will display a banner that will notify that the window is being debugged, and this appearing and disappearing as UiPath attaches to the session effectively causes the window to be scrolled up and down by 50 pixels or so, this can affect the timing of certain actions if you reduce delays and cause clicks to ‘miss’. Its easily mitigated, both with the default delays, or by suppressing the alerts, and otherwise generally works very well in my experience.
I would definently recommend you strive to migrate your interactions with Chrome/Edge to using the Chromium API input method.
Especially for improved stability and features.
These are mostly older automations, but there are quite a few of them. Some applications, or even just specific clicks/types, hovers etc have to be done with hardware events. Google needs to get it together, and maybe UiPath can talk to the right people to make it happen.
