[rust] Add support for Chrome arm64 on Linux

[dennisameling]

🔗 Related Issues

#15801

Follow-up on #16045 which added initial support for Linux arm64 (Firefox-only)

💥 What does this PR do?

Adds support for Chrome and chromedriver Linux arm64 binaries. Version 153 of Chrome for Testing adds support for his platform: https://googlechromelabs.github.io/chrome-for-testing/

⚠️ browser_latest_download_test will fail on Linux arm64 until version 153 of Chrome for Testing has been promoted to stable.

🔧 Implementation Notes

Needed to remove the hard blockers that said that Chrome for Linux arm64 wasn't supported, which is no longer the case now that official support has landed.

🤖 AI assistance

• No substantial AI assistance used
• AI assisted (complete below)
  • Tool(s): Claude Code
  • What was generated: wrote the initial code updates and tests myself, but noticed some code duplication and missing logic to properly check available download URLs, so asked Claude to write the generic find_platform_url() function.
  • I reviewed all AI output and can explain the change

💡 Additional Considerations

Bindings still need to be updated for Linux arm64: #15801 (comment)

🔄 Types of changes

• Cleanup (formatting, renaming)
• New feature (non-breaking change which adds functionality and tests!)

[qodo-code-review]

PR Summary by Qodo

Rust Selenium Manager: enable Chrome/Chromedriver downloads for Linux arm64 (CfT v153+)

✨ Enhancement 🧪 Tests 🕐 20-40 Minutes

AI Description

• Add Chrome/Chromedriver Linux arm64 support via Chrome-for-Testing endpoints.
• Enforce platform-specific minimum version (Linux arm64 requires CfT v153+).
• Update tests to skip only unsupported Edge cases and validate new arm64 behavior.

Diagram

graph TD
  A["selenium-manager CLI"] --> B["ChromeManager"] --> C["Fetch CfT JSON"] --> D{"URL exists for platform & >= min"}
  D -- "yes" --> E["Set browser/driver URL"] --> F["Download + cache"]
  D -- "no" --> G["Unavailable/min-version error"]
  B --> H["Legacy driver URL"] --> F
  H -- "linux-arm64" --> G

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Precompute a platform->url map for each downloads list

• ➕ Avoid repeated linear scans when selecting platform URLs
• ➕ Makes missing-platform handling explicit at the data-structure boundary
• ➖ More allocations/boilerplate for small lists
• ➖ Less idiomatic than a simple iterator for current usage

2. Centralize CfT "platform availability" filtering in a shared helper for browser+driver

• ➕ Reduces duplication between browser and driver version filtering rules
• ➕ Easier to maintain if CfT schemas/fields change
• ➖ Requires more refactoring across managers and test updates
• ➖ May obscure the different error semantics for browser vs driver

Recommendation: Current approach (a small find_platform_url() helper + filtering versions by URL availability) is a good balance of correctness and minimal change. The main value is the behavioral fix: selecting the newest usable version for the current platform instead of selecting a version and failing later. Consider the platform->url map only if this pattern spreads further or performance becomes a concern.

Files changed (9) +142 / -111

Enhancement (1) +89 / -65

chrome.rsEnable CfT linux-arm64 downloads with platform URL selection and min-version gating +89/-65

Enable CfT linux-arm64 downloads with platform URL selection and min-version gating

• Adds Linux arm64 support for Chrome/Chromedriver by returning the "linux-arm64" platform label and removing the previous hard blocker. Introduces 'find_platform_url()' and filters known-good versions by platform URL availability so the newest usable version wins. Applies a higher minimum (v153) for Linux arm64 downloads and improves error handling when no platform URL exists.

rust/src/chrome.rs

Tests (8) +53 / -46

browser_download_tests.rsAdjust download tests for Linux arm64 Chrome availability and Edge skips +9/-10

Adjust download tests for Linux arm64 Chrome availability and Edge skips

• Uses 'is_linux_arm64()' helper for skip logic instead of directly reading 'ARCH'. Adds a Chrome v153 download case and updates skip messaging/conditions to reflect that Chrome arm64 binaries start at v153 and Edge remains unsupported.

rust/tests/browser_download_tests.rs

browser_tests.rsAdd Chrome/Chromedriver 153 coverage and replace unsupported-chrome test with min-version test +35/-14

Add Chrome/Chromedriver 153 coverage and replace unsupported-chrome test with min-version test

• Adds a 153.x Chrome/Chromedriver test case and refines Linux arm64 skip conditions (skip Edge always; skip Chrome only when requesting <153). Removes the prior test asserting Chrome was unsupported on Linux arm64 and adds a CLI-level test asserting proper failure below the min version.

rust/tests/browser_tests.rs

cache_tests.rsRun cache tests on Linux arm64 as well +0/-1

Run cache tests on Linux arm64 as well

• Removes the cfg-based exclusion that previously skipped cache tests on linux/aarch64, allowing the cache behavior to be validated on Linux arm64 too.

rust/tests/cache_tests.rs

cache_unit_tests.rsRemove unused SeleniumManager import +0/-1

Remove unused SeleniumManager import

• Cleans up an unused import to keep the unit test module minimal and warning-free.

rust/tests/cache_unit_tests.rs

config_tests.rsRefine config test skips to only exclude Edge on Linux arm64 +2/-3

Refine config test skips to only exclude Edge on Linux arm64

• Switches to 'is_linux_arm64()' and narrows skip logic so only Edge is skipped on Linux arm64 now that Chrome is supported.

rust/tests/config_tests.rs

exec_driver_tests.rsRefine exec-driver test skips to only exclude Edge on Linux arm64 +2/-2

Refine exec-driver test skips to only exclude Edge on Linux arm64

• Uses 'is_linux_arm64()' and updates skip logic so Linux arm64 continues testing Firefox/Chrome paths while skipping unsupported Edge.

rust/tests/exec_driver_tests.rs

offline_tests.rsSimplify offline test to always use Chrome +5/-14

Simplify offline test to always use Chrome

• Removes the Linux arm64 conditional browser selection and always runs the offline flow with Chrome.

rust/tests/offline_tests.rs

version_unit_tests.rsRemove unused SeleniumManager import +0/-1

Remove unused SeleniumManager import

• Drops an unused import to reduce warnings and keep the unit test focused on version parsing behavior.

rust/tests/version_unit_tests.rs

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📜 Skill insights (0)

1. ARM misread as arm64 ✓ Resolved 🐞 Bug ≡ Correctness

Description

ChromeManager::get_platform_label() now maps any arch matching ARCH::ARM64 to "linux-arm64", but
ARCH::ARM64 also treats the alias "arm" as ARM64. This can cause 32-bit ARM requests (e.g., "--arch
arm") to select linux-arm64 Chrome/driver artifacts and fail or retrieve incompatible binaries.

Code

rust/src/chrome.rs[R517-518]

+        } else if ARM64.is(arch) {
+            "linux-arm64"

Evidence

The new linux-arm64 mapping is triggered by ARM64.is(arch) in get_platform_label(). The
architecture matcher for ARCH::ARM64 explicitly includes "arm" as an alias, so an arch value
of "arm" will now be treated as ARM64 and mapped to the linux-arm64 CfT platform label.

rust/src/chrome.rs[506-520]
rust/src/config.rs[189-205]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`get_platform_label()` uses `ARM64.is(arch)` to decide whether to return `"linux-arm64"`. However, `ARCH::ARM64` currently accepts the string alias `"arm"`, which can represent 32-bit ARM, not ARM64. This makes `--arch arm` route to the ARM64 download platform label.

### Issue Context
- `ARCH::ARM64` includes `"arm"` as an alias.
- The PR introduced an `ARM64` branch in `ChromeManager::get_platform_label()` that returns `"linux-arm64"`.

### Fix Focus Areas
- Prefer one of:
 - Remove `"arm"` from the ARM64 alias list (and/or move it to ARMV7), OR
 - Make the linux-arm64 branch stricter (match only `"arm64"`/`"aarch64"` explicitly) and let `"arm"` be handled as ARMV7/unsupported.
- Consider adding/adjusting a regression test for `--os linux --arch arm` to ensure it does not map to `linux-arm64`.

- rust/src/chrome.rs[506-520]
- rust/src/config.rs[189-205]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. arm now means ARMV7 ✗ Dismissed 📘 Rule violation ≡ Correctness ⭐ New

Description

The alias arm was moved from ARCH::ARM64 to ARCH::ARMV7, which changes the user-visible
behavior of --arch arm and can break existing scripts that previously relied on it selecting
arm64. Add explicit compatibility guidance (warning/error + docs/help text) so callers know to use
arm64/aarch64 for 64-bit.

Code

rust/src/config.rs[R195-197]

+            ARCH::ARM64 => vec![ARCH_ARM64, "aarch64"],
+            // "arm" is the conventional name for 32-bit ARM (e.g. std::env::consts::ARCH)
+            ARCH::ARMV7 => vec![ARCH_ARM7L, "armv7l", "arm"],

Evidence

PR Compliance ID 389266 requires maintaining backward-compatible public API/behavior. The changed
alias list removes arm from ARCH::ARM64 and adds it to ARCH::ARMV7, and the CLI passes
--arch directly into normalization logic, so --arch arm now resolves to 32-bit ARM instead of
arm64.

Rule 389266: Maintain backward-compatible public API and ABI
rust/src/config.rs[195-197]
rust/src/lib.rs[1388-1398]
rust/src/main.rs[94-97]
rust/tests/config_unit_tests.rs[82-99]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The meaning of `--arch arm` changed: it no longer matches `ARCH::ARM64` and instead matches `ARCH::ARMV7`. This is a user-visible behavior change that can break existing callers and should provide migration guidance.

## Issue Context
`ARCH::to_str_vector()` drives `ARCH::is()` matching, which is used by `get_normalized_arch()` to normalize the CLI-provided `--arch` value.

## Fix Focus Areas
- rust/src/config.rs[195-197]
- rust/src/lib.rs[1388-1402]
- rust/src/main.rs[94-97]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. Extra URL allocations ✓ Resolved 🐞 Bug ➹ Performance

Description

ChromeManager::find_platform_url() always clones the URL String, but it is called inside per-version
filters (e.g., request_good_driver_version_from_online) where the result is only checked with
is_some(), causing unnecessary allocations while scanning many versions.

Code

rust/src/chrome.rs[R137-140]

+        downloads
+            .iter()
+            .find(|p| p.platform.eq_ignore_ascii_case(self.get_platform_label()))
+            .map(|p| p.url.to_string())

Evidence

The helper allocates a new String for the URL, and the driver-version scan calls it inside a filter
over all known-good versions while only using .is_some(), which implies repeated unnecessary
allocations during that scan.

rust/src/chrome.rs[136-141]
rust/src/chrome.rs[225-235]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`ChromeManager::find_platform_url()` returns `Option<String>` and clones the URL via `to_string()`. In filtering code paths that iterate across many versions, the helper is used only to check availability (`.is_some()`), so the URL is repeatedly allocated and immediately dropped.

### Issue Context
This was introduced by adding the generic `find_platform_url()` helper and then reusing it both for (a) “does this version have a download for my platform?” checks and (b) “store the chosen URL for later download” assignments.

### Fix Focus Areas
- rust/src/chrome.rs[136-141]
- rust/src/chrome.rs[225-235]

### Suggested fix
- Split the helper into a non-allocating predicate / borrowed lookup, e.g.:
 - `fn has_platform_download(&self, downloads: &[PlatformUrl]) -> bool` (uses `.any(...)`)
 - and/or `fn find_platform_url_ref<'a>(&self, downloads: &'a [PlatformUrl]) -> Option<&'a str>`
- Use the boolean/borrowed helper in `filter(...)` paths.
- Only allocate (`to_string()`) at the point where you assign into `self.driver_url` / `self.browser_url`.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Context

✅ Compliance rules (platform): 14 rules

Tip of the day

💡 Did you know, you can add REVIEW.md to your repo root and Qodo follows it on every PR

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

Previous review results

Review updated until commit 6d018ad

Results up to commit 84cb7f5 ⚖️ Balanced

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Extra URL allocations ✓ Resolved 🐞 Bug ➹ Performance

Description

ChromeManager::find_platform_url() always clones the URL String, but it is called inside per-version
filters (e.g., request_good_driver_version_from_online) where the result is only checked with
is_some(), causing unnecessary allocations while scanning many versions.

Code

rust/src/chrome.rs[R137-140]

+        downloads
+            .iter()
+            .find(|p| p.platform.eq_ignore_ascii_case(self.get_platform_label()))
+            .map(|p| p.url.to_string())

Evidence

The helper allocates a new String for the URL, and the driver-version scan calls it inside a filter
over all known-good versions while only using .is_some(), which implies repeated unnecessary
allocations during that scan.

rust/src/chrome.rs[136-141]
rust/src/chrome.rs[225-235]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`ChromeManager::find_platform_url()` returns `Option<String>` and clones the URL via `to_string()`. In filtering code paths that iterate across many versions, the helper is used only to check availability (`.is_some()`), so the URL is repeatedly allocated and immediately dropped.

### Issue Context
This was introduced by adding the generic `find_platform_url()` helper and then reusing it both for (a) “does this version have a download for my platform?” checks and (b) “store the chosen URL for later download” assignments.

### Fix Focus Areas
- rust/src/chrome.rs[136-141]
- rust/src/chrome.rs[225-235]

### Suggested fix
- Split the helper into a non-allocating predicate / borrowed lookup, e.g.:
 - `fn has_platform_download(&self, downloads: &[PlatformUrl]) -> bool` (uses `.any(...)`)
 - and/or `fn find_platform_url_ref<'a>(&self, downloads: &'a [PlatformUrl]) -> Option<&'a str>`
- Use the boolean/borrowed helper in `filter(...)` paths.
- Only allocate (`to_string()`) at the point where you assign into `self.driver_url` / `self.browser_url`.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Results up to commit a3f2d83 ⚖️ Balanced

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. ARM misread as arm64 ✓ Resolved 🐞 Bug ≡ Correctness

Description

ChromeManager::get_platform_label() now maps any arch matching ARCH::ARM64 to "linux-arm64", but
ARCH::ARM64 also treats the alias "arm" as ARM64. This can cause 32-bit ARM requests (e.g., "--arch
arm") to select linux-arm64 Chrome/driver artifacts and fail or retrieve incompatible binaries.

Code

rust/src/chrome.rs[R517-518]

+        } else if ARM64.is(arch) {
+            "linux-arm64"

Evidence

The new linux-arm64 mapping is triggered by ARM64.is(arch) in get_platform_label(). The
architecture matcher for ARCH::ARM64 explicitly includes "arm" as an alias, so an arch value
of "arm" will now be treated as ARM64 and mapped to the linux-arm64 CfT platform label.

rust/src/chrome.rs[506-520]
rust/src/config.rs[189-205]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`get_platform_label()` uses `ARM64.is(arch)` to decide whether to return `"linux-arm64"`. However, `ARCH::ARM64` currently accepts the string alias `"arm"`, which can represent 32-bit ARM, not ARM64. This makes `--arch arm` route to the ARM64 download platform label.

### Issue Context
- `ARCH::ARM64` includes `"arm"` as an alias.
- The PR introduced an `ARM64` branch in `ChromeManager::get_platform_label()` that returns `"linux-arm64"`.

### Fix Focus Areas
- Prefer one of:
 - Remove `"arm"` from the ARM64 alias list (and/or move it to ARMV7), OR
 - Make the linux-arm64 branch stricter (match only `"arm64"`/`"aarch64"` explicitly) and let `"arm"` be handled as ARMV7/unsupported.
- Consider adding/adjusting a regression test for `--os linux --arch arm` to ensure it does not map to `linux-arm64`.

- rust/src/chrome.rs[506-520]
- rust/src/config.rs[189-205]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

[qodo-code-review]

Code review by qodo was updated up to the latest commit a3f2d83

[qodo-code-review]

Code review by qodo was updated up to the latest commit 680d018

[dennisameling]

Confirming that this is working as expected on a Linux arm64 machine:

Chrome 152:

$ cargo run -- --browser chrome --browser-version 152 --os linux --arch arm64 --force-browser-download --debug 
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.10s
     Running `target/debug/selenium-manager --browser chrome --browser-version 152 --os linux --arch arm64 --force-browser-download --debug`
[2026-08-13T08:12:32.762Z DEBUG] chromedriver not found in PATH
[2026-08-13T08:12:32.771Z WARN ] There was an error managing chrome; using browser found in the cache
[2026-08-13T08:12:32.771Z ERROR] chrome 152 not available for download on arm64 (minimum version: 153). Check available versions at https://googlechromelabs.github.io/chrome-for-testing/

Chrome 153:

$ cargo run -- --browser chrome --browser-version 153 --arch arm64 --force-browser-download --debug 
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.12s
     Running `target/debug/selenium-manager --browser chrome --browser-version 153 --arch arm64 --force-browser-download --debug`
[2026-08-13T08:12:53.057Z DEBUG] chromedriver not found in PATH
[2026-08-13T08:12:53.059Z DEBUG] Required browser: chrome 153.0.8005.0
[2026-08-13T08:12:53.059Z DEBUG] chrome 153.0.8005.0 already exists at /home/parallels/.cache/selenium/chrome/linux-arm64/153.0.8005.0/chrome
[2026-08-13T08:12:53.060Z DEBUG] chrome 153.0.8005.0 is available at /home/parallels/.cache/selenium/chrome/linux-arm64/153.0.8005.0/chrome
[2026-08-13T08:12:53.061Z DEBUG] Required driver: chromedriver 153.0.8005.0
[2026-08-13T08:12:53.061Z DEBUG] chromedriver 153.0.8005.0 already in the cache
[2026-08-13T08:12:53.062Z INFO ] Driver path: /home/parallels/.cache/selenium/chromedriver/linux-arm64/153.0.8005.0/chromedriver
[2026-08-13T08:12:53.062Z INFO ] Browser path: /home/parallels/.cache/selenium/chrome/linux-arm64/153.0.8005.0/chrome

[qodo-code-review]

No code changes since the last review — review skipped

[cgoldberg]

ignore my last comment.. I just saw "browser_latest_download_test will fail on Linux arm64 until version 153 of Chrome for Testing has been promoted to stable." :)

expected failure until version 153 of Chrome for Testing has been promoted to stable.