Chrome driver architecture setting is ignored and can result in downloading x64 binary into arm64 folder

[gpaciga]

Expected Behavior

When specifying the arm64 architecture for chrome drivers, selenium-standalone should download the arm64 architecture, even if running in an x64 process.

Current Behavior

compute-download-urls.js ignores the wantedArchitecture argument. This means I can specify that I want the arm64 architecture, but if process.arch says I'm running in x64, then it'll download the x64 binary.

https://github.com/webdriverio/selenium-standalone/blob/a40cb25a53f05fabcd6b8c248c2c7a4d39ae61c4/lib/compute-download-urls.js#L111C38-L111C56

However, compute-fs-paths.js correctly saves the driver into .selenium/chromedriver/latest-arm64, meaning that an x64 binary gets downloaded into a folder labelled as if it contains an arm64 binary.

For me, this was leading to difficult to diagnose performance problems, because the chromedriver binary kept running the Intel translation layer on my M1 macbook.

Steps to Reproduce

WDIO services config:

  services: [["selenium-standalone", {
    installArgs: {drivers: {chrome: {arch: 'arm64'}}},
    args: {drivers: {chrome: {arch: 'arm64'}}},
  }]],

when running in a Rosetta terminal (x64 architecture) on an M1 mac.

Alternatively:

npx selenium-standalone install --singleDriverInstall=chrome --drivers.chrome.arch=arm64

Logs

----------
selenium-standalone installation starting
----------

---
selenium install:
from: https://github.com/SeleniumHQ/selenium/releases/download/selenium-4.4.0/selenium-server-4.4.0.jar
to: /Users/gpaciga/selenium-standalone-arch/node_modules/selenium-standalone/.selenium/selenium-server/4.4.0/selenium-server.jar
---
chrome install:
from: https://chromedriver.storage.googleapis.com/114.0.5735.90/chromedriver_mac64.zip
to: /Users/gpaciga/selenium-standalone-arch/node_modules/selenium-standalone/.selenium/chromedriver/latest-arm64/chromedriver


-----
selenium-standalone installation finished
-----

Your Environment

• Version of selenium-standalone that you are using: 8.11, but dates back to at least 7.19.1
• Is there another tool calling selenium-standalone on your behalf: WebdriverIO
• System/platform: Macbook pro M1
• Run install command within an x64 terminal

[christian-bromann]

Thanks for reporting!

Just fyi: I am personally not interested maintaining this package much further and plan to either continue to maintain the NPM chromedriver package or build a new one depending on how giggio/node-chromedriver#400 will be resolved. That said, I am happy to merge PRs and make releases for this package moving on.

We greatly appreciate any contributions that help resolve the bug. While we understand that active contributors have their own priorities, we kindly request your assistance if you rely on this bug being fixed. We encourage you to take a look at our contribution guidelines or join our friendly Discord development server, where you can ask any questions you may have. Thank you for your support, and cheers!

[udarrr]

it has been resolved in #827