Chrome V86: RPA running slowly ignoring !ReplaySpeed [Solved]

kron78 · October 11, 2020, 12:11pm

Looks like I spoke too soon. The issue is still happening.

trexem · October 12, 2020, 2:18pm

Yup, still not working
Reinstalled Chrome and UI.Vision and still going so slow. Tried disabling the Throttling flag and still going so slow.
I guess I’ll try to go back to version 85 of chrome or something

newuserkantu · October 12, 2020, 2:38pm

Try firefox is better like browser.

I use firefox portable with some addons is fast and working well you can run multiple instance in same time to have multi threads.

No problem with firefox and it’s the only browser to run multiple work in same time.

trexem · October 12, 2020, 3:18pm

it’s not that easy to change the browser. But i guess I’ll do it.
have to change tons of code that worked with chrome path and chromelike windows :c
thak you @newuserkantu, i guess it is for better to change now than keep developing stuff in chrome

newuserkantu · October 12, 2020, 3:49pm

I prefer firefox for 3 things

firefox require less memory of Chrome
With firefox I can open multiple browser in same time, need only to create new folder with firefox portable (need not to create multiple profile like Chrome hard and slow).
With firefox you can run unlimited browser in few minutes if you need.
If i have a problem (corrupted browser or corrupted addon) I simple delete folder with firefox portable and recreate new folder and run again browser and ui vision in 30 seconds.

I use portable version only.

Harry · October 12, 2020, 3:52pm

I have the same problem with my scripts.

This happens only on browser chrome 86.0.4240.75 (64).

This must be solved guys. What is the issue?
We cannot simply just change browsers.

newuserkantu · October 12, 2020, 4:18pm

Waiting a solution from @admin

Macro codes are compatible between firefox and chrome so it’s very easy to switch between browsers

The same macro code working in Chrome and firefox e probably in opera (with addon) and edge.

Only some Xclick and Xtype can different from various browser

trexem · October 12, 2020, 4:25pm

Here an example that we are not minimizing UI.Vision’s window, it is just not in the front and runs slowly.

Here the code, just typing a loop variable in google’s search page

{
  "Name": "test",
  "CreationDate": "2020-10-12",
  "Commands": [
    {
      "Command": "echo",
      "Target": "${!ReplaySpeed}",
      "Value": ""
    },
    {
      "Command": "store",
      "Target": "FAST",
      "Value": "!replayspeed"
    },
    {
      "Command": "store",
      "Target": "0",
      "Value": "loop"
    },
    {
      "Command": "while_v2",
      "Target": "${loop} < 60",
      "Value": ""
    },
    {
      "Command": "echo",
      "Target": "${!ReplaySpeed}",
      "Value": ""
    },
    {
      "Command": "type",
      "Target": "name=q",
      "Value": "${loop}"
    },
    {
      "Command": "executeScript_Sandbox",
      "Target": "return Number(${loop}) +1;",
      "Value": "loop"
    },
    {
      "Command": "end",
      "Target": "",
      "Value": ""
    }
  ]
}

newuserkantu · October 12, 2020, 4:34pm

It’s an important problem to solve because it’s too sloow in this mode.

waiting admin for suggestions

seed18 · October 13, 2020, 7:32am

I had just encountered the same problem.

But I fixed this by moving the ui vision window to the taskbar area (some part of the ui vision window is being overlapped with the taskbar … and that mean ui vision is still active and make the script run smoothly, not slow).

I also create a few commands to minimize and maximize window size automatically by XType ({KEY_WIN+KEY_UP} / {KEY_WIN+KEY_DOWN})

This should help skip this problem for now. But it would be better, to fix the bug from UI Vision.

chrislu · October 14, 2020, 10:11am

This is a big problem for us too. Please fix as soon as possible! Thank you

admin · October 14, 2020, 11:13am

We confirmed the problem. This issue is triggered by the most recent Chrome update V86. All still works fine with Chrome V85 and of course in Firefox and Edge.

From the web: Chrome V86 adds background throttling to manage the effect of your tabs. It promises to reduce the maximum load of all the tabs you aren’t looking at to a mere one percent of your CPU. These tabs have to be inactive for at least five minutes for the throttling to kick in.

At this point I am not sure if this description is correct. In my test the effect of bringing the RPA window to the background is immediately, no five minutes grace period. Also, I have not found a flag to disable it. The (old) #intensive-wake-up-throttling flag sounds good, but does not influence this new behavior.

Test:

RPA window not in foreground, but not completely covered => fast
RPA window completely in background (browser full screen) => slow
Browser full screen, but RPA window on top, in the corner => fast

We are looking into this further. Meanwhile there are some good workarounds:

Make sure a tiny bit of the RPA window is still visible. This avoids the throttling.
Or use our RPA software for Mozilla Firefox or Microsoft Edge. These browsers do not show the background throttling behavior. Your macros run in all 3 browsers without changes.

Test screencast:

PS: I will mark this workaround as solution for now. But we continue to search for a direct solution.

chrislu · October 15, 2020, 9:30am

Thanks for looking into this so quickly @admin. I’m afraid those proposed workarounds aren’t suitable for us as we have a huge number of automated scripts running from batch files as scheduled tasks, which would be too complicated to switch to a new browser. We’d really appreciate a quick solution for this one! Thank you.

admin · October 15, 2020, 10:10am

May I ask why this would be difficult? I assume you use the command line API? If you have Firefox and/or Edge installed and use hard-drive mode, the switch to a different RPA browser can be as easy as changing the path to the browser. For example see this Powershell script:

github.com

A9T9/RPA/blob/master/command-line/powershell/run two macros.ps1#L23


      
          $path_autorun_html = "c:/test/ui.vision.html"
          
          #Optional: Kill Chrome instances (if any open)
          #taskkill /F /IM chrome.exe /T 
          
          #Create log file. Here the RPA software will store the result of the macro run
          $log = "log_" + $(get-date -f MM-dd-yyyy_HH_mm_ss) + ".txt" 
          $path_log = $path_downloaddir + $log 
          
          
          #Build command line (1=CHROME, 2=FIREFOX, 3=EDGE)
          $browser = 3
          Switch ($browser) {
          1 {$cmd = "${env:ProgramFiles}\Google\Chrome\Application\chrome.exe"; break}
          2 {$cmd = "${env:ProgramFiles}\Mozilla Firefox\firefox.exe"; break} #For FIREFOX
          3 {$cmd = "${env:ProgramFiles(x86)}\Microsoft\Edge\Application\msedge.exe"; break} #For EDGE 
          }
          
          $arg = """file:///"+ $path_autorun_html + "?macro="+ $macro + "&direct=1&closeRPA="+$close+"&closeBrowser="+$close1+"&savelog="+$log+""""

chrislu · October 15, 2020, 11:00am

That’s very helpful @admin, thank you! You’re right, we could look at updating the paths to Firefox in our batch files. I’d ideally like this working in Chrome though, as we have a lot of scripts which I’d need to retest in Firefox to make sure that everything works correctly, which would be time consuming. Thanks for your help.

admin · October 15, 2020, 11:18am

Actually, if you want to replace Chrome without worrying about a changed website behavior in the new browser, then I recommend Edge, since it uses a Chromium engine inside. Whereas Firefox has its own rendering engine (Gecko).

The overall Edge browser behavior (internal timings, load times, Javascript handling, PDF support,…) is very close to Edge. Edge is available for Mac and Windows but not yet for Linux (planned).

Also, RPA for Edge and RPA for Chrome share 100% the same source code. But RPA for Firefox has a few places where we needed to add Firefox specific solutions. => Thus Edge is the best direct replacement for Chrome.

chrislu · October 21, 2020, 1:10pm

@admin Thank you. Could you please confirm that you’re working on a Chrome solution for this? It’s proving to be very time consuming to switch everything to different browsers and retest everything.

admin · October 21, 2020, 5:24pm

Confirmed. We have a few ideas on how to solve this!

admin · October 27, 2020, 5:43pm

I am happy to report that we found a very good solution for this issue. The Chrome slowdown issue is solved. => We will release an update with this fix ASAP.

admin · November 12, 2020, 12:00am

Fixed with the V5.9.3 release. Thanks again for the very helpful error reporting!