With Apple having released Big Sur there is now a need for Aarch64 support for geckodriver. We should ship support for it with the next release.

Given that we do not ship a DMG bundle we will have to release two different versions of geckodriver on Mac. One for Intel and the other for Aarch64.

For the current status of implementation in Rust see:
https://github.com/rust-lang/rust/issues/73908

Right now there is no Tier1 support for MacOS Aarch64, and as such we also don't have toolchain build jobs.

Given that Rosetta will be perfectly emulating a current x86-64 binary of geckodriver on ARM, there shouldn't be an immediate need to get this support added. Lets revisit in a couple of weeks.

As it looks like we will get aarch64 support in Rust 1.49. In bug 1678439 the beta release is used to actually build Firefox for Apple Silicon.

So lets wait for the 1.49 release, and reconsider then.

With bug 1684954 our internal rustc version will be updated to the final 1.49. With that bug fixed we can then check if we want to publish native aarch64 builds.

There are rumors that Apple might remove Rosetta 2 support in some regions earlier. As developers have seen for the 3rd beta for MacOS 11.3 some strings have been added. If that's true or not, we should be prepared for that and actually ship a ARM64 version of geckodriver.

Also all dependencies are fixed, and our build system has support for it.

With the attached patch I get a build error because the linker tries to use arm64 instead of aarch64:
https://treeherder.mozilla.org/logviewer?job_id=332653505&repo=try&lineNumber=588-592

[task 2021-03-10T08:49:54.211Z] error: linking with `cc` failed: exit code: 1
[task 2021-03-10T08:49:54.211Z]   |
[task 2021-03-10T08:49:54.211Z]   = note: "cc" "-arch" "arm64" [..]
[task 2021-03-10T08:49:54.212Z]   = note: cc: error: arm64: No such file or directory
[task 2021-03-10T08:49:54.212Z]           cc: error: unrecognized command line option '-arch'; did you mean '-march='?

Glandium, do you have an idea what's wrong here?

You need to update taskcluster/scripts/misc/build-geckodriver.sh. See what was done for cbindgen in https://phabricator.services.mozilla.com/D104978

Thanks! That looks pretty straight forward.

Joel, is there a way to run wpt (wdspec) tests on a Aarch64 MacOS device yet? We would like to make sure that when shipping the geckodriver binary for M1 is actually working.

we don't have any machines in production yet- there is a lot of paperwork and right now we are waiting on vpn connection. I didn't plan for wdspec capacity. currently on osx, these take up ~3 hours for a full set of tests. That is a lot and basically every hour of automation ~= 1 machine needed. Is there a reduced set of tests you can run? Maybe opt only, ignore headless, and a subset of the existing tests?

(In reply to Joel Maher ( :jmaher ) (UTC -0800) from comment #11)

Is there a reduced set of tests you can run? Maybe opt only, ignore headless, and a subset of the existing tests?

Running all wdspec tests shouldn't take 3h. Maybe you are confused with web-platform-tests that contain these tests. When I query mozilla-central I can see:

https://treeherder.mozilla.org/jobs?repo=mozilla-central&searchStr=wdspec%2Cship%2Cmac

So headless takes around 37minutes and non-headless 45minutes. Basically I would be happy with just a having test jobs for mozilla-central for now (maybe even nightly only). And it doesn't matter if it's headless or not. We could take what's faster.

Given that we don't have machines in production yet, I would suggest that we land this patch and have the Aarch64 binary at least build. We could mention Tier-2 support and not putting it on the official release page of geckodriver.

whimboo, can we run a subset of opt/headless? there is machine reboot and taskcluster overhead as well, per job it starts to add up.

(In reply to Joel Maher ( :jmaher ) (UTC -0800) from comment #14)

whimboo, can we run a subset of opt/headless? there is machine reboot and taskcluster overhead as well, per job it starts to add up.

I would have to forward this to James. Not sure if running wpt jobs on Taskcluster mozharness support running specific folders.

Sadly we don't have just sanity checks. But whereby what about the Rust unit tests? Would those maybe sufficient for the time being until we have a pool of M1 machines in production?

wpt tests are not scheduled for M1 nor are rust tests. We have vetted this list of tests with many people, the goal is bare minimum test coverage for the new platform, not minimum test coverage or low test coverage. Just asking for 50 machines in production has added weeks of signatures and meetings.

Sorry I was unclear. wdspec is a subset of wpt, which can be run independently. But I don't know if folder selection will work easily.

Folder selection can work; if you have a list of tests (or a test) that we could use as critical smoketests we have the ability to configure a task that just runs those. But per what jmaher says it sounds like we shouldn't expect much in the short term; nothing more than "geckodriver is able to start and create a session", and even that might be too much right now. Running the first test of a given type incurs all the overhead of creating the test environment specific to that test type, which as jmaher says can be many minutes of machine time and we're highly constrained.

That said I don't think GeckoDriver should have loads of arch-specific code so if we can verify it works at all then it would be surprising (but not impossible!) to see M1 additional specific issues in individual tests (unless they are underlying Gecko issues ofc).

Ok, then we will use the approach as layed out in comment 12 and ship aarch64 support as tier-2.

https://hg.mozilla.org/mozilla-central/rev/ccd0f12b8293

Hi Mike, during your review of my patch you offered a quick smoke test of geckodriver on an M1 device. If you find the time we would appreciate your feedback in how it works. As mentioned on Phabricator running the Wdspec tests would be the best way here. To do that you would have to run the following command:

mach wpt --webdriver-binary=path/to/geckodriver testing/web-platform/tests/webdriver/tests/

Thanks a lot!

It's taking forever, but it works.

Yes, tests take a long time to run. Thanks a lot for verifying that it works!