Chrome Update 121.0.6167.86 Issues

We have an offline installer, used on Windows Server 2019

If anyone is still looking for a workaround for this issue on Windows Server, please investigate the possibility of using a server snapshot (if your company stores them) to roll back to chrome version 120.

Once the server has been rolled back, you will need to disable Google Chrome automatic updates to prevent version .121 from being installed automatically again: ‘https://support.google.com/chrome/a/answer/6350036?hl=en#zippy=%2Cturn-off-chrome-browser-updates’

This has worked for my organization, I hope this can help someone 🤞

These instructions are for Google Workspace and Chrome Browser Enterprise Support customers only

I just want to downgrade a standalone PC.  Cannot find any instructions on how to do it.  Any ideas?

I switched to bots to use the default browser which I made Chromium on the bot runner, but you still have to go into each bot. Not a good solution.

Hi @User16594604096479542004 

If you are cloud customer try changing package version to latest one ie 2.17.2 in the task bots and give a try. If you are using On Prem or unable to see this package refer above KB to manually download and Upload the same to the Control Room-> Manage-> Packages-> Add package

hi, we downgraded chrome but it didn’t help, is there any other solution than upgrading recorder package? thank you

Upgrade the recorder worked with the latest version of chrome.

I am curious what is the best practice for avoiding these issues in the future. 

Do most enterprises run their bots on Chromium so they can control updates?  Do they turn off Chrome updates and periodically test all their bots on the latest version and they release it?

Or is what just happened a very rare situation and most enterprises just wait for a package update?

THANKS FOR ALL YOUR HELP!

The other issue we experienced is that the new package needed to be applied to > 150 bots, so we used the Update Bot process to update the packages of those bots.  Unfortunately, there is new functionality for setting timeouts when accessing a DOM element using the Recorder and this caused a lot of these bots to require manual updating (as they were using a recorder package without this functionality) so that they were able to work again.

It would have been preferable if the update process was able to default to Basic and use the value that was previously entered.

The other issue we experienced is that the new package needed to be applied to > 150 bots, so we used the Update Bot process to update the packages of those bots.  Unfortunately, there is new functionality for setting timeouts when accessing a DOM element using the Recorder and this caused a lot of these bots to require manual updating (as they were using a recorder package without this functionality) so that they were able to work again.

It would have been preferable if the update process was able to default to Basic and use the value that was previously entered.

Hallo @dwilks73 

and that’s what exactly happening, when switching to new package the action takes the previous time as basic value...

The other issue we experienced is that the new package needed to be applied to > 150 bots, so we used the Update Bot process to update the packages of those bots.  Unfortunately, there is new functionality for setting timeouts when accessing a DOM element using the Recorder and this caused a lot of these bots to require manual updating (as they were using a recorder package without this functionality) so that they were able to work again.

It would have been preferable if the update process was able to default to Basic and use the value that was previously entered.

Hallo @dwilks73 

and that’s what exactly happening, when switching to new package the action takes the previous time as basic value...

The Basic option is selected and the Wait for system response (in seconds) is blank.  I would have expected that this is filled in with the previous value, but it isn’t, it is blank so the entire bot is invalid due to this.