[🚀 Feature]: Add support for Selenium Windows ARM64 (WoA) CI builds and binaries

[Mugundanmcw]

Feature and motivation:

This issue aims to add official support for the Windows ARM64 (WoA) platform by enabling CI builds and distributing native Selenium binaries for WoA.
Currently, Selenium lacks native binaries for Windows ARM64. With the increasing adoption of ARM-based Windows devices, having native binaries for WoA would be highly beneficial for both end users and developers working on this growing platform.

Looking forward to collaborate in making necessary changes to make this happen.

Thanks in advance!

[selenium-ci]

@Mugundanmcw, thank you for creating this issue. We will troubleshoot it as soon as we can.

Selenium Triage Team: remember to follow the Triage Guide

[diemol]

@Mugundanmcw when you say binaries, do you mean the Selenium Manager binary?

[cgoldberg]

@Mugundanmcw

I think the reasons we can't (or don't) support Windows ARM64 is explained here under "Alternative architectures": https://www.selenium.dev/documentation/selenium_manager/

To summarize:

1. most browsers/drivers aren't supported on this architecture, so Selenium Manager would be unable to fetch them
2. we build Selenium Manager using GitHub Actions, and the Rust toolchain is not available on the Windows ARM64 hosted runners

I think the 2nd point is the real blocker, because if we did build Selenium Manager on Windows ARM64, users could always configure it to use whichever browser they have installed, even if we can't download it for them.

So unless you have ideas to overcome these issues, I don't think we can support Windows ARM64 at this time.

[Mugundanmcw]

Hi @cgoldberg,

1. Selenium Manager primarily supports browser automation for Chrome, Edge, and Firefox—all of which are natively available on Windows ARM64.

2. The Windows ARM64 hosted runners currently don't include a pre-installed Rust toolchain, it can be manually installed from the official website. I successfully set up the Rust toolchain manually in my CI environment and was able to build Selenium Manager natively. You can find the details in my CI setup. [workflow.yml] [Selenium-manager build Run]

Thanks!

[diemol]

Thanks for the context, @Mugundanmcw.

I think we need to change how we distribute Selenium Manager. Right now, it is packaged with the bindings, and adding one more will just make it larger.

[nvborisenko]

And this is absolutely normal to distribute native dependencies within package.

About package's footprint: current Selenium.WebDriver NuGet package is 11.94 MB. Adding one more supported platform is not a criminal. For comparison Microsoft.Playwright NuGet package is 182.04 MB

[cgoldberg]

Selenium Manager primarily supports browser automation for Chrome, Edge, and Firefox—all of which are natively available on Windows ARM64

I see that Edge is available, but Chrome-for-Testing doesn't appear to be:
https://googlechromelabs.github.io/chrome-for-testing/#stable

(at least from the location we fetch browsers from)

We would also need to make changes to the bindings and Selenium Manager. Right now we distribute a single SM executable for each platform. We would need a way to detect the architecture and select the appropriate executable to call... or change the way we package SM, so only the relevant executable is distributed for each platform and architecture.

[nvborisenko]

But chromedriver or geckodriver is not supported on arm?..

[cgoldberg]

But chromedriver or geckodriver is not supported on arm?

as far as I can tell:

• geckodriver for ARM64 is available on Windows, Linux, and Mac
• chromedriver for ARM64 is only available on Mac
• edgedriver for ARM64 is available on Windows and Mac

So Chrome-for-Testing and chromedriver for Windows ARM64 would be the missing pieces.

Note: There are unofficial builds of chromedriver for Windows ARM64. For example: https://github.com/electron/electron/releases

[nvborisenko]

Thanks for discovering! I think of supporting arm architecture seems reasonable, we cover more audience. If the platform is not supported we just raise an exception (at build/runtime is up to bindings).

[cgoldberg]

I think of supporting arm architecture seems reasonable

Besides the implications of building it in CI, we also need to address the issue I mentioned in a previous comment. The drivers all call selenium-manager.exe binary on Windows. We would need to detect the platform architecture and call the appropriate binary (selenium-manager-arm64.exe or whatever).

Not a huge change, but something that would need to be done in each binding.

I think it's reasonable to further investigate ARM support... but if we go down that road, I'd vote for supporting Linux ARM64 first, to enable use on Raspberry Pi and other systems with more marketshare than Windows ARM64 :)

[nvborisenko]

I don't see problems, it is more about planning, we are community. I propose to create general issue like "Support ARM", break down everything what should be done. And we, as a community, will do it (if @SeleniumHQ/selenium-tlc doesn't mind).