[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]

Realizing I forgot to add artifacts/selenium-manager-linux-arm64-debug/selenium-manager-linux-arm64-debug.tar to this list, so let's keep that in mind as we continue working on this PR.

[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! 🙏🏼

[cgoldberg]

@dennisameling

Thanks for your patience on this. There hasn't been much interest from the other maintainers in shipping ARM binaries for Selenium Manager. It's mostly due to percieved low interest/useage on ARM platforms (I don't necesarrily agree), lack of driver/browser support on ARM, and some concerns about inflating our package sizes (we include binaries for all platforms in universal packages).

What do you think about moving the CI changes (ci-rust.yaml) into a separate PR? I think the other changes in this PR are very helpful and will be great for anyone who wants to build and run Selenium Manager themselves. I think we can get those merged quickly, while I continue to discuss building and distributing the binaries.

Edit: I guess it's better to leave the CI as-is.. just because we build the binaries doesn't mean we need to include them as part of packages yet. Disregard my suggestion above and let's just try to get the issues in my followup comments fixed.

[cgoldberg]

@dennisameling

I checked out your branch, merged trunk, and fixed the merge conflicts and formatting issues.

I committed those changes and pushed them to your branch. Can you make sure my changes look OK?

[cgoldberg]

@dennisameling

Right now I am getting 5 failures when i run cargo test locally.

I'm running on Debian ARM64 13 (Raspberry Pi OS) with the latest rust toolchain. I am building/testing with cargo, not with Bazel, so I don't know if that does anything different? (Bazel is giving me issues on ARM)

test grid_version_test::case_1 ... FAILED
test grid_version_test::case_3 ... FAILED
test grid_version_test::case_2 ... FAILED
test grid_latest_test ... FAILED
test grid_version_test::case_4 ... FAILED

The failures all look like:

command=`"/home/cgoldberg/code/selenium/rust/target/debug/selenium-manager" "--grid" "nightly" "--output" "json"`
code=65
stdout=
{
  \"logs\": [
    {
      \"level\": \"ERROR\",
      \"timestamp\": 1764722307,
      \"message\": \"Invalid cross-device link (os error 18)\"
    }
  ],
  \"result\": {
    \"code\": 65,
    \"message\": \"Invalid cross-device link (os error 18)\",
    \"driver_path\": \"\",
    \"browser_path\": \"\"
  }
}

I also built selenium-manager from trunk branch, and I get the same failures:

$ selenium-manager --grid 4.36.0
[2025-12-03T00:42:21.022Z ERROR] Invalid cross-device link (os error 18)

... so it's not something your code introduced, but it is something we need to investigate and fix.

Do you have any idea what those failures mean, and can you reproduce them?

[cgoldberg]

The tests that fail for me locally pass on CI. Maybe I'm missing something by not using Bazel?

A different test failed on CI: https://github.com/SeleniumHQ/selenium/actions/runs/19880823913/job/56979362597?pr=16045#step:19:811