[rust] Test Selenium Manager on Linux arm64

[dennisameling]

User description

🔗 Related Issues

#15801

💥 What does this PR do?

This PR ensures that the Selenium Manager test suite passes on Linux arm64, and enables CI tests for this platform through GitHub's recently released Linux arm64 runners.

🔧 Implementation Notes

I'm new to Rust, but wanted Selenium Manager to explicitly fail if users try to run it for Chrome or Edge on Linux arm64, since it's not supported. Previously, the code would silently download linux64 binaries which are for Linux x64, and cause segfaults on Linux arm64.

The setup I went for at least ensures that Firefox/Geckodriver on Linux arm64 will work and are tested properly as well.

💡 Additional Considerations

• After merging this PR, additional work has to be done to actually release the Linux arm64 binary for Selenium Manager, and include it in the main Selenium packages somehow.
• The docs at https://www.selenium.dev/documentation/selenium_manager/#alternative-architectures will need to be updated if the team is open to merging this PR. I'm happy to open a separate PR for that if desired.

🔄 Types of changes

• New feature (non-breaking change which adds functionality and tests!)

---

PR Type

Enhancement

---

Description

• Add Linux ARM64 support for Selenium Manager

• Enable CI testing on GitHub's ARM64 runners

• Restrict Chrome/Edge to Firefox-only on ARM64

• Update test suite for ARM64 compatibility

---

Changes diagram

flowchart LR
  A["Linux ARM64 Detection"] --> B["Browser Support Check"]
  B --> C["Firefox: Supported"]
  B --> D["Chrome/Edge: Error"]
  E["Test Suite Updates"] --> F["ARM64 Conditional Logic"]
  G["CI Configuration"] --> H["GitHub ARM64 Runners"]

Loading

---

Changes walkthrough 📝

	Relevant files
Error handling	2 files chrome.rs Add ARM64 unsupported error for Chrome                                      +2/-0      edge.rs Add ARM64 unsupported error for Edge                                          +3/-0
Tests	11 files browser_download_tests.rs Skip non-Firefox tests on ARM64                                                    +23/-16  browser_tests.rs Skip non-Firefox browser tests on ARM64                                    +9/-0      cache_tests.rs Disable cache tests on ARM64                                                          +1/-0      config_tests.rs Skip non-Firefox config tests on ARM64                                      +5/-0      exec_driver_tests.rs Skip non-Firefox driver tests on ARM64                                      +5/-0      mirror_tests.rs Use Firefox for ARM64 mirror tests                                              +2/-2      offline_tests.rs Use Firefox for ARM64 offline tests                                            +10/-5    output_tests.rs Use Firefox for ARM64 output tests                                              +28/-13  proxy_tests.rs Use Firefox for ARM64 proxy tests                                                +10/-4    stable_browser_tests.rs Skip non-Firefox stable tests on ARM64                                      +6/-0      webview_tests.rs Disable webview tests on ARM64                                                      +1/-0
Enhancement	1 files common.rs Add ARM64 detection helper function                                            +6/-0
Configuration changes	1 files ci-rust.yml Add Ubuntu ARM64 runner to CI                                                        +1/-0

---

Need help?

Type /help how to ... in the comments thread for any questions about Qodo Merge usage.

Check out the documentation for more information.

[qodo-code-review]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

🎫 Ticket compliance analysis 🔶 15801 - Partially compliant Compliant requirements: • Enable CI builds for ARM64 systems (Linux arm64 CI added) • Support ARM-based systems (Linux arm64 support added) Non-compliant requirements: • Add official support for Windows ARM64 (WoA) platform (only Linux arm64 implemented) • Distribute native Selenium binaries for ARM64 (Windows ARM64 not addressed) • Support ARM-based Windows devices (Windows ARM64 not implemented) Requires further human verification: • Verify that Firefox/Geckodriver works correctly on Linux arm64 hardware • Confirm CI pipeline executes successfully on GitHub's arm64 runners • Test that error messages for unsupported browsers are user-friendly

⏱️ Estimated effort to review: 3 🔵🔵🔵⚪⚪

🧪 PR contains tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Wrong Error Message The error message mentions "Google Chrome" when it should mention "Microsoft Edge" since this is in the Edge manager code. return Err(anyhow!("Linux arm64 is not supported yet by Google Chrome. Please try another browser.")); } else { Logic Error The condition logic appears inverted - the original code skipped Edge on Windows, but the new code runs tests for Edge on Windows and skips other cases. if browser.eq("edge") && OS.eq("windows") { return } else if OS.eq("linux") && ARCH.eq("aarch64") && !browser.eq("firefox") { return }

[qodo-code-review]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
General	✅ Fix incorrect browser name in error Suggestion Impact: The commit implemented the suggested fix by changing the error message from "Google Chrome" to "Microsoft Edge" in the Linux arm64 unsupported error code diff: - return Err(anyhow!("Linux arm64 is not supported yet by Google Chrome. Please try another browser.")); + return Err(anyhow!( + "Linux arm64 is not supported yet by Microsoft Edge. Please try another browser." + )); The error message incorrectly mentions "Google Chrome" when this is the Edge browser manager. Update the error message to correctly reference Microsoft Edge instead of Chrome. rust/src/edge.rs [292-293] } else if LINUX.is(os) && ARM64.is(arch) { - return Err(anyhow!("Linux arm64 is not supported yet by Google Chrome. Please try another browser.")); + return Err(anyhow!("Linux arm64 is not supported yet by Microsoft Edge. Please try another browser.")); [Suggestion processed] Suggestion importance[1-10]: 8 __ Why: This is a valid and important correction, as the error message in the EdgeManager incorrectly references "Google Chrome" due to a copy-paste error.	Medium
	✅ Add missing semicolons after return Suggestion Impact: The commit directly implemented the suggestion by adding semicolons after both return statements in the specified code block code diff: - return + return; } else if OS.eq("linux") && ARCH.eq("aarch64") && !browser.eq("firefox") { - return + return; Add semicolons after the return statements to follow Rust conventions. While not required, explicit semicolons improve code consistency and readability. rust/tests/browser_download_tests.rs [31-35] if browser.eq("edge") && OS.eq("windows") { - return + return; } else if OS.eq("linux") && ARCH.eq("aarch64") && !browser.eq("firefox") { - return + return; } [Suggestion processed] Suggestion importance[1-10]: 4 __ Why: The suggestion correctly points out that semicolons are missing, and adding them improves code style and consistency, which is a good practice in Rust.	Low
	✅ Add missing semicolon after return Suggestion Impact: The suggestion was implemented by adding semicolons after return statements in two locations in the code code diff: - return + return; } let mut cmd = get_selenium_manager(); @@ -84,7 +84,7 @@ #[case] error_code: i32, ) { if OS.eq("linux") && ARCH.eq("aarch64") && !browser.eq("firefox") { - return + return; Add a semicolon after the return statement to follow Rust conventions and maintain consistency with other return statements in the codebase. rust/tests/browser_tests.rs [44-46] if OS.eq("linux") && ARCH.eq("aarch64") && !browser.eq("firefox") { - return + return; } [Suggestion processed] Suggestion importance[1-10]: 4 __ Why: The suggestion correctly points out a missing semicolon after a return statement, and adding it improves code style and consistency with Rust conventions.	Low
Update

[cgoldberg]

Thanks. I'll leave code review for someone who knows rust.

But I'm a little confused...

Previously, the code would silently download linux64 binaries which are for Linux x64, and cause segfaults on Linux arm64.

I thought we weren't building Selenium Manager on ARM. Were you running the linux64 binaries through QEMU or something?

Does this PR enable building Selenium Manager for arm64, or just handle the situation when trying to run the linux64 binaries on arm64? If the former, don't we need to update the various bindings and packaging to accommodate this? ... or is this just a step towards enabling Selenium on ARM64?

[dennisameling]

Sorry for the confusion here.

I thought we weren't building Selenium Manager on ARM.

Indeed. There have been no Selenium Manager builds for ARM. This PR is a step towards enabling Selenium on ARM64.

The reason I mentioned linux64 is that if you look at this code path for example, without any changes for Linux ARM64, the code would just have downloaded the linux64 Chrome binary because it's in the else branch. But Linux ARM64 can't work with that natively, which is why I added this logic to explicitly tell the user that this scenario isn't supported until Chrome provides native binaries for this platform.

This PR will at least ensure that users of Linux arm64 can use Firefox, which has official binaries for this platform 👍🏼 whenever Edge and Chrome start publishing native binaries too, they can be added through a follow-up PR.

[cgoldberg]

OK... that makes sense, but it's probably more appropriate to make these changes if/when we start building SM for ARM since these code paths won't be tested or used until then.

[dennisameling]

With regards to testing, that's why I added https://github.com/SeleniumHQ/selenium/pull/16045/files#diff-5162db340096b281e8c77ef016f0595e9b7a63e9cb48605a43b685301b4b5ee0R38 so that it will start running the tests on native Linux arm64 runners. GitHub released those in Public Preview in January of this year, and quite some open source projects have started using them already.

I was hoping - by just adding the testing part to CI for now - that the team can at least be confident that the code will work on Linux arm64, and leave the actual builds/publishing for a follow-up PR. But happy to look into that part as well if helpful.

[diemol]

@bonigarcia, do we need to explicitly build a SM binary for ARM?

[bonigarcia]

The code looks good to me (thanks a lot for contributing, @dennisameling!).

I don't have an ARM machine to test it. Let's see what CI says about it.

@diemol Yes, we would need to build SM for ARM in Linux. And then, we would need to distribute the new binary together with the other three. Also, the bindings would need to discover the system architecture (in Linux) to use the X64 or ARM SM binary.

[dennisameling]

Given that all the tests are passing, I just added the necessary logic to publish builds for Linux arm64 as well. I see that some preparations have already been done to start using them in the Python binding.

Is there anything I can help with to push this over the finish line? Thanks! 😊

[cgoldberg]

@dennisameling

Thanks! I was the one who did the work to prepare the Python bindings. I want to test building and running Selenium Manager and the Python bindings locally for Linux arm64. Since my only machine is x86, I am going to get a Raspberry Pi next weekend (I'm not even sure if that's the right ARM architecture?)

Hopefully I can get things building and running, and that will give us more confidence to move forward with building for ARM in CI.

Your changes are very helpful and I will update this issue in a week or so once I've had time to play with it.

[dennisameling]

I am going to get a Raspberry Pi next weekend (I'm not even sure if that's the right ARM architecture?)

Nice! The Raspberry Pi 3, 4 and 5 are all arm64, so you should be good there. I've been testing natively on an Ubuntu arm64 VM in Parallels on Mac, and can confirm that at least the Rust part is working as expected 👍🏼

[cgoldberg]

@dennisameling

I bought a raspberry pi, and everything was surprisingly easy to setup. I was able to build selenium-manager on Raspberry Pi OS (Debian Stable) without problems using our Python source package and setuptools-rust. I will continue looking into your PR and update this in a few days.

[dennisameling]

@cgoldberg is there anything I can do to help push this over the finish line? Happy to update/change things if needed. Thanks! 😊

[cgoldberg]

I should have some time to get back to it soon and I'll let you know if there's anything else you can do. I appreciate your patience 🙂

[dennisameling]

@cgoldberg quick reminder for this one. Anything I can do to help? Thanks! 🙏🏼

[dennisameling]

@cgoldberg apologies for the silence on my side - I had many other things going on and didn't have bandwidth to look into this. Thank you for testing this so thoroughly!

I just addressed your comments, and also noticed that Edge was actually downloaded for x64 before throwing that error. I just improved the logic so that the error is thrown before selenium-manager even tries to download the binaries.

$ ./selenium-manager --clear-cache --force-browser-download --arch=arm64 --os=linux --browser=edge
[2026-02-02T17:47:53.301Z ERROR] Linux arm64 is not supported yet by edge. Please try another browser.

$ ./selenium-manager --clear-cache --force-browser-download --arch=arm64 --os=linux --browser=chrome
[2026-02-02T17:49:17.867Z ERROR] Linux arm64 is not supported yet by chrome. Please try another browser.

$ ./selenium-manager --clear-cache --force-browser-download --arch=arm64 --os=linux --browser=firefox
[2026-02-02T17:49:51.077Z INFO ] Driver path: /usr/bin/geckodriver
[2026-02-02T17:49:51.077Z INFO ] Browser path: /home/parallels/.cache/selenium/firefox/linux-arm64/147.0.2/firefox

Would you mind testing on your end again? Thanks!

[cgoldberg]

@dennisameling I'll take a look.. thanks!

[qodo-code-review]

Code Review by Qodo

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

1. Chrome error template args mismatch ✓ Resolved 📘 Rule violation ≡ Correctness

Description

UNAVAILABLE_DOWNLOAD_WITH_MIN_VERSION_ERR_MSG now contains 4 {} placeholders, but
Chrome/ChromeManager still formats it with format_three_args, producing malformed user-facing
minimum-version errors with unreplaced/misplaced fields. This reduces diagnostic value and can
obscure the real failure reason when that error path is hit.

Code

rust/src/lib.rs[106]

+    "{} {} not available for download on {} (minimum version: {})";

Evidence

Rule 6 requires user-helpful visibility around errors, but the citations show the shared template in
rust/src/lib.rs has been updated to include four replacement slots (including a new `(minimum
version: {}) portion) and a corresponding format_four_args()` helper, while the Chrome
implementation in rust/src/chrome.rs continues to call format_three_args(...) with only three
values; as a result, the rendered error will leave the last {} unreplaced and/or shift values
(e.g., the on ... field), creating misleading or broken diagnostics.

AGENTS.md: Add User-Helpful Logging Where Insight Is Needed
rust/src/lib.rs[105-106]
rust/src/chrome.rs[212-220]
rust/src/chrome.rs[212-221]
rust/src/lib.rs[1975-1988]

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 public error template `UNAVAILABLE_DOWNLOAD_WITH_MIN_VERSION_ERR_MSG` was changed to require 4 formatting arguments, but at least one existing call site (Chrome/ChromeManager) still formats it with only 3 arguments, resulting in malformed user-facing error output when the minimum-version error path is triggered.

## Issue Context
`rust/src/lib.rs` now defines `UNAVAILABLE_DOWNLOAD_WITH_MIN_VERSION_ERR_MSG` as `"{} {} not available for download on {} (minimum version: {})"` and adds `format_four_args()`. However, `rust/src/chrome.rs` still uses `format_three_args(UNAVAILABLE_DOWNLOAD_WITH_MIN_VERSION_ERR_MSG, ...)`, which leaves an unreplaced `{}` in the output and can misplace values (including the `on ...` field), reducing user diagnosability and violating the expectation of clear error messaging.

## Fix Focus Areas
- rust/src/lib.rs[105-106]
- rust/src/chrome.rs[212-221]
- rust/src/lib.rs[1982-1988]

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

---

2. Geckodriver ARM64 URL regression 🐞 Bug ≡ Correctness

Description

FirefoxManager::get_driver_url now always uses ARM64 archive names for aarch64, which contradicts
the existing unit test expectations for geckodriver v0.31.0 aarch64 and will fail those tests (and
likely 404 for older versions). This is introduced by removing the version gate around selecting
ARM64 driver labels.

Code

rust/src/firefox.rs[R329-332]

+            } else if ARM64.is(arch) {
                "win-aarch64.zip"
            } else {
                "win64.zip"

Evidence

The new ARM64 branches in get_driver_url() always choose win-aarch64.zip / linux-aarch64.tar.gz
for aarch64, but the existing unit test enumerates that geckodriver 0.31.0 with aarch64 must
resolve to linux64.tar.gz / win64.zip and asserts exact URL equality, so it will fail after this
change.

rust/src/firefox.rs[321-346]
rust/src/firefox.rs[744-760]
rust/src/firefox.rs[771-778]
rust/src/firefox.rs[799-805]

Agent prompt

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

### Issue description
`FirefoxManager::get_driver_url()` now selects `*-aarch64` driver archives for **all** ARM64 geckodriver versions. Existing unit tests explicitly expect that for geckodriver `0.31.0` on `aarch64`, the URL uses the `linux64`/`win64` artifacts.

### Issue Context
This PR removed the `minor_driver_version > 31` check, changing behavior for older geckodriver versions.

### Fix Focus Areas
- rust/src/firefox.rs[321-346]
- rust/src/firefox.rs[684-806]

### What to change
- Reintroduce a version gate (e.g., only use `linux-aarch64` / `win-aarch64` when geckodriver version >= 0.32.0), OR explicitly error on ARM64 when the requested geckodriver version is below the first ARM64-capable release.
- Update `unit_tests::test_driver_url` expectations to match the chosen behavior (either legacy fallback URLs or explicit error assertions).

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

---

3. ARM64 tests skip assertions ✓ Resolved 📘 Rule violation ≡ Correctness

Description

On Linux aarch64, several tests return early instead of asserting the newly intended failures
for Chrome/Edge unsupported behavior and the Firefox version gate, leaving the new ARM64 error paths
untested. This reduces regression coverage for the newly introduced “unsupported on Linux arm64”
behavior and increases regression risk.

Code

rust/tests/browser_tests.rs[R48-50]

+    if OS.eq("linux") && ARCH.eq("aarch64") && !browser.eq("firefox") {
+        return;
+    }

Evidence

Compliance ID 4 requires behavior changes to be covered by tests when feasible, but the PR adds new
Linux aarch64 error branches in ChromeManager/EdgeManager and a Firefox version gate while the
tests add Linux arm64 skips that return or println! and therefore never execute or validate
those new paths. In particular, browser_latest_download_test skips all non-Firefox cases on Linux
arm64, which prevents asserting that the manager fails with the expected “unsupported on Linux
arm64” behavior for Chrome/Edge (and similarly avoids exercising the new Firefox version
constraint).

AGENTS.md: Add or update tests for fixes/features; prefer small unit tests and avoid mocks
rust/src/chrome.rs[421-424]
rust/src/chrome.rs[495-503]
rust/src/edge.rs[323-326]
rust/src/edge.rs[398-406]
rust/src/firefox.rs[600-608]
rust/tests/browser_tests.rs[48-50]
rust/tests/browser_download_tests.rs[31-35]
rust/tests/browser_download_tests.rs[69-80]
rust/tests/browser_download_tests.rs[26-35]

Agent prompt

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

## Issue description
New ARM64-specific behavior was introduced (Chrome/Edge unsupported on Linux arm64; Firefox Linux arm64 requires version >=136), but the test suite largely skips these scenarios via early returns/prints instead of asserting the expected failure. Update the tests to validate the intended non-zero exit and expected error message/behavior so the new Linux `aarch64` branches remain covered and regressions are caught.

## Issue Context
The PR adds explicit `Err(anyhow!(...))` branches for Linux `aarch64` in `ChromeManager`/`EdgeManager` and a version gate in `FirefoxManager`. Current tests (including `browser_latest_download_test`) avoid running these paths on Linux arm64 by returning early for non-Firefox cases (and otherwise skipping behavior), which prevents validating the newly introduced unsupported-platform behavior and Firefox version constraint.

## Fix Focus Areas
- rust/tests/browser_tests.rs[48-92]
- rust/tests/browser_download_tests.rs[30-98]
- rust/tests/browser_download_tests.rs[26-35]
- rust/src/chrome.rs[421-503]
- rust/src/edge.rs[323-406]
- rust/src/firefox.rs[600-608]

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

---

View more (1)

4. Arm CI skips cleanup ✓ Resolved 🐞 Bug ☼ Reliability

Description

The new tests matrix adds ubuntu-24.04-arm, but the shared Bazel workflow only runs key Ubuntu
setup/cleanup steps when inputs.os == 'ubuntu'. This can leave preinstalled browsers/drivers on
the ARM runner and make the new CI signal unreliable or non-deterministic.

Code

.github/workflows/ci-rust.yml[R30-32]

          - os: macos
          - os: ubuntu
+          - os: ubuntu-24.04-arm

Evidence

ci-rust.yml adds ubuntu-24.04-arm to the Bazel-driven tests matrix. In bazel.yml,
Ubuntu-specific steps are guarded by exact equality inputs.os == 'ubuntu', which will not match
the new value, so those steps are skipped for the ARM job.

.github/workflows/ci-rust.yml[23-37]
.github/workflows/bazel.yml[100-167]

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 Bazel reusable workflow gates Ubuntu-specific setup/cleanup using exact string equality (`inputs.os == 'ubuntu'`). The PR introduces a new OS value (`ubuntu-24.04-arm`), so those steps do not run for the ARM job.

## Issue Context
`ci-rust.yml` passes `os: ubuntu-24.04-arm` into `bazel.yml`. In `bazel.yml`, steps like deleting browsers/drivers and freeing disk space are guarded with `inputs.os == 'ubuntu'`, which will not match `ubuntu-24.04-arm`.

## Fix Focus Areas
- .github/workflows/ci-rust.yml[23-37]
- .github/workflows/bazel.yml[100-167]

Suggested change: update Bazel workflow conditions to treat any Ubuntu runner label as Ubuntu (e.g., `startsWith(inputs.os, 'ubuntu')`) so cleanup/setup runs for `ubuntu-24.04-arm` too.

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

---

5. Chrome CfT path untested 🐞 Bug ≡ Correctness

Description

The new Chrome linux-arm64 test pins chromedriver to v114, which avoids the CfT (>=115) branch in
ChromeManager::get_driver_url and therefore doesn’t validate the intended “fail fast on Linux arm64”
behavior for modern chromedriver versions. In the CfT branch, get_driver_url can set and return a
CfT-derived URL using get_platform_label()=="linux64" on Linux, bypassing the later Linux arm64
rejection logic.

Code

rust/tests/browser_tests.rs[R138-141]

+    // Below the CfT threshold so the driver URL is composed offline, exercising the arm64 branch.
+    manager.set_driver_version("114.0.5735.90".to_string());
+    let error = manager.get_driver_url().unwrap_err();
+    assert!(error.to_string().contains("not supported yet"));

Evidence

The test intentionally sets a pre-CfT driver version, while the Chrome implementation uses a
different code path for driver major versions >=115 that returns a CfT-derived URL early and uses
get_platform_label()=="linux64" for Linux; this bypasses the later Linux arm64 guard that exists
only in the offline URL composition branch.

rust/tests/browser_tests.rs[133-142]
rust/src/chrome.rs[389-405]
rust/src/chrome.rs[422-428]
rust/src/chrome.rs[476-489]

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 new test `chrome_driver_url_is_unsupported_on_linux_arm64` uses chromedriver `114.0.5735.90` specifically to stay below the CfT threshold, so it never exercises the CfT path used for chromedriver versions >= 115. This leaves the “unsupported on Linux arm64” behavior unverified for the primary/modern path, and the current implementation can still return a linux64 CfT URL on Linux arm64.

## Issue Context
`ChromeManager::get_driver_url()` calls `request_good_driver_version_from_online()` for major versions >= 115 and returns `self.driver_url` immediately if set, which occurs before the offline URL composition block that contains the Linux arm64 rejection.

## Fix Focus Areas
- rust/tests/browser_tests.rs[133-142]
- rust/src/chrome.rs[389-405]
- rust/src/chrome.rs[422-428]
- rust/src/chrome.rs[476-489]

### Suggested changes
1) Add/modify a test to cover a chromedriver version >= 115 (e.g., `115.0.5790.102` or any 115+ string) and assert that Linux arm64 is rejected.
2) Update `ChromeManager::get_driver_url()` (or `request_good_driver_version_from_online()` / `get_platform_label()`) to short-circuit with the same Linux arm64 “not supported yet” error *before* any CfT request/early return, so the test is deterministic and no network is required.

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

---

6. Firefox cache label mismatch ✓ Resolved 🐞 Bug ≡ Correctness

Description

FirefoxManager::get_platform_label() now always returns win-arm64/linux-arm64 for ARM64, but
get_driver_url() still selects win64/linux64 archives when geckodriver minor version <= 31. This
makes cache layout/matching inconsistent with the downloaded artifact selection for older
geckodriver versions on ARM64.

Code

rust/src/firefox.rs[R414-416]

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

Evidence

get_driver_url() still uses minor_driver_version > 31 to select *-aarch64 archives, while
get_platform_label() now returns arm64 labels unconditionally. This divergence makes
platform-based cache paths and cache scanning inconsistent with what gets downloaded for older
versions.

rust/src/firefox.rs[319-359]
rust/src/firefox.rs[399-419]

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()` no longer considers geckodriver version, but `get_driver_url()` still does. On ARM64 with older geckodriver versions (<= 0.31.x), this creates a mismatch between cache platform label (`linux-arm64`/`win-arm64`) and the actual archive selected (`linux64`/`win64`).

## Issue Context
`get_driver_url()` has explicit version gating for aarch64 binaries (minor > 31). The PR removed the same gating from `get_platform_label()`, so platform label always becomes arm64 even when the driver URL is not.

## Fix Focus Areas
- rust/src/firefox.rs[319-359]
- rust/src/firefox.rs[399-419]

Suggested change: either (a) restore version-aware platform labeling (derive label from driver_version like before), or (b) if ARM64 and requested geckodriver <= 0.31.x, fail explicitly instead of falling back to `linux64`/`win64` archives (and keep platform label consistent with that behavior).

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

---

7. Mirror test wrong mirror ✓ Resolved 🐞 Bug ≡ Correctness

Description

On Linux arm64, mirror_test switches to Firefox but still passes a ChromeDriver mirror URL and
--browser-version 112. This makes the test invalid on arm64 (it either fails for the wrong reason
or passes without actually validating Firefox/geckodriver mirror behavior).

Code

rust/tests/mirror_tests.rs[R27-31]

+        if is_linux_arm64() {
+            "firefox"
+        } else {
+            "chrome"
+        },

Evidence

The test now chooses firefox on Linux arm64 but still uses a chromedriver mirror URL and a fixed
version argument, which does not correspond to geckodriver/Firefox mirror testing.

rust/tests/mirror_tests.rs[22-45]

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 mirror test conditionally changes `--browser` to Firefox on Linux arm64, but it keeps `--driver-mirror-url` pointing to a chromedriver mirror and retains a Chrome-oriented `--browser-version` value.

## Issue Context
This test is intended to validate mirror behavior for driver downloads. Switching browsers without updating the mirror URL (and version argument) breaks the test's meaning on ARM64.

## Fix Focus Areas
- rust/tests/mirror_tests.rs[22-45]

Suggested change: either (a) keep testing Chrome mirror behavior by skipping the test on Linux arm64, or (b) if using Firefox on arm64, update `--driver-mirror-url` to a geckodriver mirror and use an appropriate Firefox version (or remove `--browser-version` if not required for the mirror assertion).

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

---

8. Min-version error omits OS 🐞 Bug ◔ Observability

Description

download_browser() formats the min-version error as "... on {}" but passes only self.get_arch(),
even though minimum downloadable versions can differ by OS+arch (e.g., Firefox uses different
minimums for Windows ARM64 vs Linux ARM64). This reduces diagnostic clarity for users hitting the
min-version gate.

Code

rust/src/lib.rs[R256-259]

                self.get_browser_name(),
                &major_browser_version,
+                self.get_arch(),
                &min_browser_version_for_download.to_string(),

Evidence

The shared download error formatter passes only self.get_arch() into the new on {} placeholder,
while Firefox’s min-version computation is explicitly OS+arch dependent (Windows ARM64 differs from
Linux ARM64), so the message does not uniquely identify the platform context.

rust/src/lib.rs[247-266]
rust/src/firefox.rs[519-536]
rust/src/firefox.rs[64-68]

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 min-version download error message includes a new `on {}` slot, but the implementation passes only `self.get_arch()`. For OS-dependent minimums, the message is ambiguous.

### Issue Context
Firefox’s `get_min_browser_version_for_download()` now uses OS+arch distinctions (Windows ARM64 vs Linux ARM64), so the error should ideally identify the platform.

### Fix Focus Areas
- rust/src/lib.rs[247-266]
- rust/src/firefox.rs[519-536]

### What to change
- Consider passing `self.get_platform_label()` instead of `self.get_arch()`.
- Alternatively, change the message to include both OS and arch (e.g., `... on {} {}`) and pass `self.get_os()` and `self.get_arch()`.

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

---

_{To customize comments, go to the Qodo configuration screen, or learn more in the docs.}

Previous review results

Review updated until commit 329d35b ⚖️ Balanced

Results up to commit 997e56a ⚖️ Balanced

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

1. ARM64 tests skip assertions ✓ Resolved 📘 Rule violation ≡ Correctness

Description

On Linux aarch64, several tests return early instead of asserting the newly intended failures
for Chrome/Edge unsupported behavior and the Firefox version gate, leaving the new ARM64 error paths
untested. This reduces regression coverage for the newly introduced “unsupported on Linux arm64”
behavior and increases regression risk.

Code

rust/tests/browser_tests.rs[R48-50]

+    if OS.eq("linux") && ARCH.eq("aarch64") && !browser.eq("firefox") {
+        return;
+    }

Evidence

Compliance ID 4 requires behavior changes to be covered by tests when feasible, but the PR adds new
Linux aarch64 error branches in ChromeManager/EdgeManager and a Firefox version gate while the
tests add Linux arm64 skips that return or println! and therefore never execute or validate
those new paths. In particular, browser_latest_download_test skips all non-Firefox cases on Linux
arm64, which prevents asserting that the manager fails with the expected “unsupported on Linux
arm64” behavior for Chrome/Edge (and similarly avoids exercising the new Firefox version
constraint).

AGENTS.md: Add or update tests for fixes/features; prefer small unit tests and avoid mocks
rust/src/chrome.rs[421-424]
rust/src/chrome.rs[495-503]
rust/src/edge.rs[323-326]
rust/src/edge.rs[398-406]
rust/src/firefox.rs[600-608]
rust/tests/browser_tests.rs[48-50]
rust/tests/browser_download_tests.rs[31-35]
rust/tests/browser_download_tests.rs[69-80]
rust/tests/browser_download_tests.rs[26-35]

Agent prompt

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

## Issue description
New ARM64-specific behavior was introduced (Chrome/Edge unsupported on Linux arm64; Firefox Linux arm64 requires version >=136), but the test suite largely skips these scenarios via early returns/prints instead of asserting the expected failure. Update the tests to validate the intended non-zero exit and expected error message/behavior so the new Linux `aarch64` branches remain covered and regressions are caught.

## Issue Context
The PR adds explicit `Err(anyhow!(...))` branches for Linux `aarch64` in `ChromeManager`/`EdgeManager` and a version gate in `FirefoxManager`. Current tests (including `browser_latest_download_test`) avoid running these paths on Linux arm64 by returning early for non-Firefox cases (and otherwise skipping behavior), which prevents validating the newly introduced unsupported-platform behavior and Firefox version constraint.

## Fix Focus Areas
- rust/tests/browser_tests.rs[48-92]
- rust/tests/browser_download_tests.rs[30-98]
- rust/tests/browser_download_tests.rs[26-35]
- rust/src/chrome.rs[421-503]
- rust/src/edge.rs[323-406]
- rust/src/firefox.rs[600-608]

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

---

2. Arm CI skips cleanup ✓ Resolved 🐞 Bug ☼ Reliability

Description

The new tests matrix adds ubuntu-24.04-arm, but the shared Bazel workflow only runs key Ubuntu
setup/cleanup steps when inputs.os == 'ubuntu'. This can leave preinstalled browsers/drivers on
the ARM runner and make the new CI signal unreliable or non-deterministic.

Code

.github/workflows/ci-rust.yml[R30-32]

          - os: macos
          - os: ubuntu
+          - os: ubuntu-24.04-arm

Evidence

ci-rust.yml adds ubuntu-24.04-arm to the Bazel-driven tests matrix. In bazel.yml,
Ubuntu-specific steps are guarded by exact equality inputs.os == 'ubuntu', which will not match
the new value, so those steps are skipped for the ARM job.

.github/workflows/ci-rust.yml[23-37]
.github/workflows/bazel.yml[100-167]

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 Bazel reusable workflow gates Ubuntu-specific setup/cleanup using exact string equality (`inputs.os == 'ubuntu'`). The PR introduces a new OS value (`ubuntu-24.04-arm`), so those steps do not run for the ARM job.

## Issue Context
`ci-rust.yml` passes `os: ubuntu-24.04-arm` into `bazel.yml`. In `bazel.yml`, steps like deleting browsers/drivers and freeing disk space are guarded with `inputs.os == 'ubuntu'`, which will not match `ubuntu-24.04-arm`.

## Fix Focus Areas
- .github/workflows/ci-rust.yml[23-37]
- .github/workflows/bazel.yml[100-167]

Suggested change: update Bazel workflow conditions to treat any Ubuntu runner label as Ubuntu (e.g., `startsWith(inputs.os, 'ubuntu')`) so cleanup/setup runs for `ubuntu-24.04-arm` too.

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

---

3. Mirror test wrong mirror ✓ Resolved 🐞 Bug ≡ Correctness

Description

On Linux arm64, mirror_test switches to Firefox but still passes a ChromeDriver mirror URL and
--browser-version 112. This makes the test invalid on arm64 (it either fails for the wrong reason
or passes without actually validating Firefox/geckodriver mirror behavior).

Code

rust/tests/mirror_tests.rs[R27-31]

+        if is_linux_arm64() {
+            "firefox"
+        } else {
+            "chrome"
+        },

Evidence

The test now chooses firefox on Linux arm64 but still uses a chromedriver mirror URL and a fixed
version argument, which does not correspond to geckodriver/Firefox mirror testing.

rust/tests/mirror_tests.rs[22-45]

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 mirror test conditionally changes `--browser` to Firefox on Linux arm64, but it keeps `--driver-mirror-url` pointing to a chromedriver mirror and retains a Chrome-oriented `--browser-version` value.

## Issue Context
This test is intended to validate mirror behavior for driver downloads. Switching browsers without updating the mirror URL (and version argument) breaks the test's meaning on ARM64.

## Fix Focus Areas
- rust/tests/mirror_tests.rs[22-45]

Suggested change: either (a) keep testing Chrome mirror behavior by skipping the test on Linux arm64, or (b) if using Firefox on arm64, update `--driver-mirror-url` to a geckodriver mirror and use an appropriate Firefox version (or remove `--browser-version` if not required for the mirror assertion).

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

---

4. Firefox cache label mismatch ✓ Resolved 🐞 Bug ≡ Correctness

Description

FirefoxManager::get_platform_label() now always returns win-arm64/linux-arm64 for ARM64, but
get_driver_url() still selects win64/linux64 archives when geckodriver minor version <= 31. This
makes cache layout/matching inconsistent with the downloaded artifact selection for older
geckodriver versions on ARM64.

Code

rust/src/firefox.rs[R414-416]

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

Evidence

get_driver_url() still uses minor_driver_version > 31 to select *-aarch64 archives, while
get_platform_label() now returns arm64 labels unconditionally. This divergence makes
platform-based cache paths and cache scanning inconsistent with what gets downloaded for older
versions.

rust/src/firefox.rs[319-359]
rust/src/firefox.rs[399-419]

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()` no longer considers geckodriver version, but `get_driver_url()` still does. On ARM64 with older geckodriver versions (<= 0.31.x), this creates a mismatch between cache platform label (`linux-arm64`/`win-arm64`) and the actual archive selected (`linux64`/`win64`).

## Issue Context
`get_driver_url()` has explicit version gating for aarch64 binaries (minor > 31). The PR removed the same gating from `get_platform_label()`, so platform label always becomes arm64 even when the driver URL is not.

## Fix Focus Areas
- rust/src/firefox.rs[319-359]
- rust/src/firefox.rs[399-419]

Suggested change: either (a) restore version-aware platform labeling (derive label from driver_version like before), or (b) if ARM64 and requested geckodriver <= 0.31.x, fail explicitly instead of falling back to `linux64`/`win64` archives (and keep platform label consistent with that behavior).

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

---

Results up to commit 3d40a8e ⚖️ Balanced

No changes from previous review

Results up to commit bb2f80a ⚖️ Balanced

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

1. Geckodriver ARM64 URL regression 🐞 Bug ≡ Correctness

Description

FirefoxManager::get_driver_url now always uses ARM64 archive names for aarch64, which contradicts
the existing unit test expectations for geckodriver v0.31.0 aarch64 and will fail those tests (and
likely 404 for older versions). This is introduced by removing the version gate around selecting
ARM64 driver labels.

Code

rust/src/firefox.rs[R329-332]

+            } else if ARM64.is(arch) {
                "win-aarch64.zip"
            } else {
                "win64.zip"

Evidence

The new ARM64 branches in get_driver_url() always choose win-aarch64.zip / linux-aarch64.tar.gz
for aarch64, but the existing unit test enumerates that geckodriver 0.31.0 with aarch64 must
resolve to linux64.tar.gz / win64.zip and asserts exact URL equality, so it will fail after this
change.

rust/src/firefox.rs[321-346]
rust/src/firefox.rs[744-760]
rust/src/firefox.rs[771-778]
rust/src/firefox.rs[799-805]

Agent prompt

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

### Issue description
`FirefoxManager::get_driver_url()` now selects `*-aarch64` driver archives for **all** ARM64 geckodriver versions. Existing unit tests explicitly expect that for geckodriver `0.31.0` on `aarch64`, the URL uses the `linux64`/`win64` artifacts.

### Issue Context
This PR removed the `minor_driver_version > 31` check, changing behavior for older geckodriver versions.

### Fix Focus Areas
- rust/src/firefox.rs[321-346]
- rust/src/firefox.rs[684-806]

### What to change
- Reintroduce a version gate (e.g., only use `linux-aarch64` / `win-aarch64` when geckodriver version >= 0.32.0), OR explicitly error on ARM64 when the requested geckodriver version is below the first ARM64-capable release.
- Update `unit_tests::test_driver_url` expectations to match the chosen behavior (either legacy fallback URLs or explicit error assertions).

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

---

2. Chrome error template args mismatch ✓ Resolved 📘 Rule violation ≡ Correctness

Description

UNAVAILABLE_DOWNLOAD_WITH_MIN_VERSION_ERR_MSG now contains 4 {} placeholders, but
Chrome/ChromeManager still formats it with format_three_args, producing malformed user-facing
minimum-version errors with unreplaced/misplaced fields. This reduces diagnostic value and can
obscure the real failure reason when that error path is hit.

Code

rust/src/lib.rs[106]

+    "{} {} not available for download on {} (minimum version: {})";

Evidence

Rule 6 requires user-helpful visibility around errors, but the citations show the shared template in
rust/src/lib.rs has been updated to include four replacement slots (including a new `(minimum
version: {}) portion) and a corresponding format_four_args()` helper, while the Chrome
implementation in rust/src/chrome.rs continues to call format_three_args(...) with only three
values; as a result, the rendered error will leave the last {} unreplaced and/or shift values
(e.g., the on ... field), creating misleading or broken diagnostics.

AGENTS.md: Add User-Helpful Logging Where Insight Is Needed
rust/src/lib.rs[105-106]
rust/src/chrome.rs[212-220]
rust/src/chrome.rs[212-221]
rust/src/lib.rs[1975-1988]

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 public error template `UNAVAILABLE_DOWNLOAD_WITH_MIN_VERSION_ERR_MSG` was changed to require 4 formatting arguments, but at least one existing call site (Chrome/ChromeManager) still formats it with only 3 arguments, resulting in malformed user-facing error output when the minimum-version error path is triggered.

## Issue Context
`rust/src/lib.rs` now defines `UNAVAILABLE_DOWNLOAD_WITH_MIN_VERSION_ERR_MSG` as `"{} {} not available for download on {} (minimum version: {})"` and adds `format_four_args()`. However, `rust/src/chrome.rs` still uses `format_three_args(UNAVAILABLE_DOWNLOAD_WITH_MIN_VERSION_ERR_MSG, ...)`, which leaves an unreplaced `{}` in the output and can misplace values (including the `on ...` field), reducing user diagnosability and violating the expectation of clear error messaging.

## Fix Focus Areas
- rust/src/lib.rs[105-106]
- rust/src/chrome.rs[212-221]
- rust/src/lib.rs[1982-1988]

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

---

3. Min-version error omits OS 🐞 Bug ◔ Observability

Description

download_browser() formats the min-version error as "... on {}" but passes only self.get_arch(),
even though minimum downloadable versions can differ by OS+arch (e.g., Firefox uses different
minimums for Windows ARM64 vs Linux ARM64). This reduces diagnostic clarity for users hitting the
min-version gate.

Code

rust/src/lib.rs[R256-259]

                self.get_browser_name(),
                &major_browser_version,
+                self.get_arch(),
                &min_browser_version_for_download.to_string(),

Evidence

The shared download error formatter passes only self.get_arch() into the new on {} placeholder,
while Firefox’s min-version computation is explicitly OS+arch dependent (Windows ARM64 differs from
Linux ARM64), so the message does not uniquely identify the platform context.

rust/src/lib.rs[247-266]
rust/src/firefox.rs[519-536]
rust/src/firefox.rs[64-68]

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 min-version download error message includes a new `on {}` slot, but the implementation passes only `self.get_arch()`. For OS-dependent minimums, the message is ambiguous.

### Issue Context
Firefox’s `get_min_browser_version_for_download()` now uses OS+arch distinctions (Windows ARM64 vs Linux ARM64), so the error should ideally identify the platform.

### Fix Focus Areas
- rust/src/lib.rs[247-266]
- rust/src/firefox.rs[519-536]

### What to change
- Consider passing `self.get_platform_label()` instead of `self.get_arch()`.
- Alternatively, change the message to include both OS and arch (e.g., `... on {} {}`) and pass `self.get_os()` and `self.get_arch()`.

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

---

Results up to commit fe81f84 ⚖️ Balanced

No changes from previous review

Results up to commit 064f8d7 ⚖️ Balanced

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

1. Chrome CfT path untested 🐞 Bug ≡ Correctness

Description

The new Chrome linux-arm64 test pins chromedriver to v114, which avoids the CfT (>=115) branch in
ChromeManager::get_driver_url and therefore doesn’t validate the intended “fail fast on Linux arm64”
behavior for modern chromedriver versions. In the CfT branch, get_driver_url can set and return a
CfT-derived URL using get_platform_label()=="linux64" on Linux, bypassing the later Linux arm64
rejection logic.

Code

rust/tests/browser_tests.rs[R138-141]

+    // Below the CfT threshold so the driver URL is composed offline, exercising the arm64 branch.
+    manager.set_driver_version("114.0.5735.90".to_string());
+    let error = manager.get_driver_url().unwrap_err();
+    assert!(error.to_string().contains("not supported yet"));

Evidence

The test intentionally sets a pre-CfT driver version, while the Chrome implementation uses a
different code path for driver major versions >=115 that returns a CfT-derived URL early and uses
get_platform_label()=="linux64" for Linux; this bypasses the later Linux arm64 guard that exists
only in the offline URL composition branch.

rust/tests/browser_tests.rs[133-142]
rust/src/chrome.rs[389-405]
rust/src/chrome.rs[422-428]
rust/src/chrome.rs[476-489]

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 new test `chrome_driver_url_is_unsupported_on_linux_arm64` uses chromedriver `114.0.5735.90` specifically to stay below the CfT threshold, so it never exercises the CfT path used for chromedriver versions >= 115. This leaves the “unsupported on Linux arm64” behavior unverified for the primary/modern path, and the current implementation can still return a linux64 CfT URL on Linux arm64.

## Issue Context
`ChromeManager::get_driver_url()` calls `request_good_driver_version_from_online()` for major versions >= 115 and returns `self.driver_url` immediately if set, which occurs before the offline URL composition block that contains the Linux arm64 rejection.

## Fix Focus Areas
- rust/tests/browser_tests.rs[133-142]
- rust/src/chrome.rs[389-405]
- rust/src/chrome.rs[422-428]
- rust/src/chrome.rs[476-489]

### Suggested changes
1) Add/modify a test to cover a chromedriver version >= 115 (e.g., `115.0.5790.102` or any 115+ string) and assert that Linux arm64 is rejected.
2) Update `ChromeManager::get_driver_url()` (or `request_good_driver_version_from_online()` / `get_platform_label()`) to short-circuit with the same Linux arm64 “not supported yet” error *before* any CfT request/early return, so the test is deterministic and no network is required.

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

---

Results up to commit 1b0949d ⚖️ Balanced

No changes from previous review

[qodo-code-review]

Code review by qodo was updated up to the latest commit 3d40a8e

[qodo-code-review]

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

[qodo-code-review]

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

[qodo-code-review]

Code review by qodo was updated up to the latest commit 064f8d7

[qodo-code-review]

Code review by qodo was updated up to the latest commit 1b0949d

[qodo-code-review]

Code review by qodo was updated up to the latest commit 329d35b