[rust] Fix Windows arm64 logic for Selenium Manager and prepare CI for running the test suite

[dennisameling]

User description

🔗 Related Issues

#15801

💥 What does this PR do?

This PR fixes two issues that were preventing the Rust test suite to fully pass on Windows on ARM. While running the tests locally on an arm64 machine, I ran into these errors:

    {
      \"level\": \"ERROR\",
      \"timestamp\": 1752338536,
      \"message\": \"Unsuccessful response (404 Not Found) for URL https://ftp.mozilla.org/pub/firefox/releases/128.12.0esr/win-aarch64/en-US/Firefox%20Setup%20128.12.0esr.exe\"
    }

and

thread 'electron_version_test::case_1' panicked at /rustc/6b00bc3880198600130e1cf62b8f8a93494488cc\library\core\src\ops\function.rs:250:5:
Unexpected failure.
code=65
stderr=```""```
command=`"C:\\repos\\selenium\\rust\\target\\debug\\selenium-manager.exe" "--browser" "electron" "--driver-version" "36.2.1"`
code=65
stdout="[2025-07-12T16:48:12.883Z ERROR] Unsuccessful response (404 Not Found) for URL https://github.com/electron/electron/releases/download/v36.2.1/chromedriver-v36.2.1-win32-arm64-x64.zip\n"
stderr=""

It turned out that the arch names for Windows arm64 were incorrect in the Rust code. Confirmed that these are valid URLs:

https://ftp.mozilla.org/pub/firefox/releases/128.12.0esr/win64-aarch64/en-US/Firefox%20Setup%20128.12.0esr.exe
https://github.com/electron/electron/releases/download/v36.2.1/chromedriver-v36.2.1-win32-arm64.zip

I want to emphasize that Windows ARM64 can run x64 binaries under emulation. So even though e.g. Chrome doesn't have a native Chromedriver yet, Windows ARM64 can run the x64 version under emulation.

This means that the following browsers/drivers will work on Windows ARM64:

Browser	Architecture	Test status
Chrome + Chromedriver	x64 (emulated)	✅ (runs under emulation)
Firefox + Geckodriver	arm64	✅ runs natively
Edge + EdgeDriver	arm64	✅ runs natively
Electron driver	arm64	✅ runs natively

I can confirm that the Rust test suite is passing locally on my Windows arm64 machine.

🔧 Implementation Notes

💡 Additional Considerations

• After merging this PR, additional work has to be done to actually release the Windows 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

• Bug fix (backwards compatible)
• New feature (non-breaking change which adds functionality and tests!)

---

PR Type

Bug fix

---

Description

• Fix Windows ARM64 platform labels in Selenium Manager

• Correct Firefox ARM64 URL path from win-aarch64 to win64-aarch64

• Fix Electron ARM64 platform label from win32-arm64-x64 to win32-arm64

• Add Windows ARM64 CI testing support

---

Changes diagram

flowchart LR
  A["Windows ARM64 Detection"] --> B["Firefox Platform Label"]
  A --> C["Electron Platform Label"]
  B --> D["win64-aarch64 URL"]
  C --> E["win32-arm64 URL"]
  F["CI Configuration"] --> G["Windows ARM64 Testing"]

Loading

---

Changes walkthrough 📝

	Relevant files
Bug fix	electron.rs Correct Electron ARM64 platform label                                        rust/src/electron.rs Fix Windows ARM64 platform label from win32-arm64-x64 to win32-arm64 +1/-1      firefox.rs Correct Firefox ARM64 platform label                                          rust/src/firefox.rs Fix Windows ARM64 platform label from win-aarch64 to win64-aarch64 +1/-1
Enhancement	ci-rust.yml Enable Windows ARM64 CI testing                                                    .github/workflows/ci-rust.yml Add windows-11-arm to CI test matrix +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 Windows ARM64 • Add official support for Windows ARM64 (WoA) platform Non-compliant requirements: • Distribute native Selenium binaries for Windows ARM64 Requires further human verification: • Verify that CI builds actually produce and distribute native binaries for Windows ARM64 • Confirm that the platform label fixes resolve the 404 errors mentioned in PR description

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

🧪 PR contains tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Platform Label Verify that the corrected platform label 'win32-arm64' matches the actual URL structure used by Electron releases for Windows ARM64 downloads "win32-arm64" } else { Platform Label Verify that the corrected platform label 'win64-aarch64' matches the actual URL structure used by Firefox releases for Windows ARM64 downloads platform_label = "win64-aarch64"; } else {

[qodo-code-review]

PR Code Suggestions ✨

No code suggestions found for the PR.

[cgoldberg]

After merging this PR, additional work has to be done to actually release the Windows arm64 binary for Selenium Manager, and include it in the main Selenium packages somehow.

When this happens, all the bindings will need to be updated to use the correct version of Selenium Manager when running on ARM.

Currently, we ship all versions of Selenium Manager on all platforms. When runninng on Windows, the bindings just use selenium-manager.exe. We will need to ship the ARM executable with a different name (selenium-manager-arm64.exe or something), and the bindings will have to detect the architecture and call the appropriate exexutable.

[dennisameling]

So the tests in CI have failed. It's trying to pass MSVC build arguments like /nologo to clang, which apparently has been hardcoded in the ring library for Windows arm64 🙃

Interestingly, doing cargo build and cargo test on Windows arm64 in the rust folder work fine. Only bazel test --test_env=RUST_BACKTRACE=full --test_env=RUST_TEST_NOCAPTURE=1 --flaky_test_attempts=3 //rust/... is what's failing.

I'm not sure why the bazel test command is showing different results than doing a cargo test in the rust folder directly. Tried to debug things a bit, but failed and don't have time to look further now unfortunately.

[cgoldberg]

@dennisameling

I'll see if someone with better knowledge of Rust and Bazel than me can take a look.

btw, feel free to join other developers in chat via Slack/IRC/Matrix. There are usually people monitoring the #selenium and #selenium-tlc channels:

https://www.selenium.dev/support/#ChatRoom

[dennisameling]

Quick update: I've just filed an issue in the ring repository together with a PR that should allow things to work when building with MSVC for arm64. Let's see 🤞🏼

[dennisameling]

@cgoldberg GitHub actions had an outage yesterday, causing the jobs to have been skipped. Mind kicking off the pipeline one more time? Thanks!

[cgoldberg]

1 test failed in CI, but it's totally unrelated to these changes.. I'll kick it off again just to see if we get a fully green run.

[dennisameling]

The apple-flat-package package transitively pulls in ring via apple-xar → cryptographic-message-syntax → ring which causes the Bazel tests to fail on Windows arm64. The related issue is briansmith/ring#2215. It passes MSVC build flags to the clang compiler which it was forced to use on Windows arm64.

[dennisameling]

ring just merged in briansmith/ring#2803, which should fix the build on Windows arm64. They haven't released a new version yet, but have been merging a lot of PRs in the last few weeks, so I'd expect a new release relatively soon.

[dennisameling]

Same problem with the ring dependency here; using rustls-tls pulls in ring and causes the Bazel tests to fail

[dennisameling]

ring just merged in briansmith/ring#2803, which should fix the build on Windows arm64. They haven't released a new version yet, but have been merging a lot of PRs in the last few weeks, so I'd expect a new release relatively soon.

[dennisameling]

The default value here is ["aarch64-apple-darwin", "aarch64-unknown-linux-gnu", "wasm32-unknown-unknown", "wasm32-wasip1", "x86_64-pc-windows-msvc", "x86_64-unknown-linux-gnu", "x86_64-unknown-nixos-gnu"], so I had to explicitly add aarch64-pc-windows-msvc, otherwise Bazel would happily skip the build and tests on Windows arm64. That caused the tests to "succeed" in CI, but in reality they were just skipped. Docs: https://bazelbuild.github.io/rules_rust/crate_universe_bzlmod.html#from_cargo

[dennisameling]

Just ran some tests locally on a Windows arm64 VM:

PS > & '.\selenium-manager.exe' --clear-cache --arch=arm64 --browser=firefox   
[2026-03-13T09:44:17.746Z INFO ] Driver path: C:\Users\dennisameling\.cache\selenium\geckodriver\win-arm64\0.36.0\geckodriver.exe
[2026-03-13T09:44:17.747Z INFO ] Browser path: C:\Users\dennisameling\.cache\selenium\firefox\win-arm64\148.0.2\firefox.exe

PS > & '.\selenium-manager.exe' --clear-cache --arch=arm64 --browser=edge                         
[2026-03-13T09:42:38.359Z INFO ] Driver path: C:\Users\dennisameling\.cache\selenium\msedgedriver\win-arm64\144.0.3719.162\msedgedriver.exe
[2026-03-13T09:42:38.359Z INFO ] Browser path: C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe

Note that Chrome for Testing doesn't support Windows arm64 yet (as opposed to the main Chrome browser that users would typically download), so it falls back to the x64 version that can run under emulation on Windows arm64:

& '.\selenium-manager.exe' --clear-cache --arch=arm64 --browser=chrome    
[2026-03-13T09:45:55.174Z INFO ] Driver path: C:\Users\dennisameling\.cache\selenium\chromedriver\win64\146.0.7680.76\chromedriver.exe
[2026-03-13T09:45:55.175Z INFO ] Browser path: C:\Users\dennisameling\.cache\selenium\chrome\win64\146.0.7680.76\chrome.exe

[MugundanMCW]

Hi @dennisameling and @cgoldberg
Could you share some updates on the status of the PR? Is there are any blockers?