**What happens?**:
I used what I believe to be the latest fresh:
```
# fresh: 22.05.1
# image: docker-registry.wikimedia.org/releng/node14-test-browser:0.0.2-s4
# software: Debian GNU/Linux 11 (bullseye)
# Node.js v14.17.5 (npm 7.21.0)
# Chromium 97.0.4692.99
# Mozilla Firefox 91.5.0esr
# JSDuck 5.3.4 (Ruby 2.7.4) ruby 2.7.4p191
# mount: /mediawiki ➟ /Users/montehurd/mediawiki-test/mediawiki (read-write)
# /mediawiki/.git ➟ /Users/montehurd/mediawiki-test/mediawiki/.git (read-only)
```
I followed mediawiki setup instructions here:
https://gerrit.wikimedia.org/g/mediawiki/core/+/HEAD/DEVELOPERS.md
Running `npm run selenium-test`, I see the following:
```
lines=15,counterexample
nobody@docker-desktop:/mediawiki$ npm run selenium-test
> selenium-test
> wdio ./tests/selenium/wdio.conf.js
Execution of 5 workers started at 2022-05-20T22:15:19.540Z
[0-2] RUNNING in chrome - /tests/selenium/specs/user.js
[0-1] RUNNING in chrome - /tests/selenium/specs/recentchanges.js
[0-0] RUNNING in chrome - /tests/selenium/specs/page.js
[0-3] RUNNING in chrome - /tests/selenium/specs/watchlist.js
[0-0] 2022-05-20T22:15:59.605Z ERROR @wdio/runner: Error: connect ECONNREFUSED 127.0.0.1:59207
[0-0] at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1148:16)
[0-3] 2022-05-20T22:15:59.625Z ERROR @wdio/runner: Error: connect ECONNREFUSED 127.0.0.1:56115
[0-3] at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1148:16)
[0-2] 2022-05-20T22:15:59.624Z ERROR @wdio/runner: Error: connect ECONNREFUSED 127.0.0.1:56655
[0-2] at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1148:16)
[0-1] 2022-05-20T22:15:59.639Z ERROR @wdio/runner: Error: connect ECONNREFUSED 127.0.0.1:60141
[0-1] at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1148:16)
[0-0] RETRYING in chrome - /tests/selenium/specs/page.js
[0-1] RETRYING in chrome - /tests/selenium/specs/recentchanges.js
[0-2] RETRYING in chrome - /tests/selenium/specs/user.js
[0-3] RETRYING in chrome - /tests/selenium/specs/watchlist.js
[0-0] RUNNING in chrome - /tests/selenium/specs/page.js
[0-2] RUNNING in chrome - /tests/selenium/specs/user.js
[0-3] RUNNING in chrome - /tests/selenium/specs/watchlist.js
[0-1] RUNNING in chrome - /tests/selenium/specs/recentchanges.js
[0-0] 2022-05-20T22:16:38.766Z ERROR @wdio/runner: Error: connect ECONNREFUSED 127.0.0.1:58619
[0-0] at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1148:16)
[0-2] 2022-05-20T22:16:38.914Z ERROR @wdio/runner: Error: connect ECONNREFUSED 127.0.0.1:56295
[0-2] at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1148:16)
[0-3] 2022-05-20T22:16:38.918Z ERROR @wdio/runner: Error: connect ECONNREFUSED 127.0.0.1:55895
[0-3] at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1148:16)
[0-0] FAILED in chrome - /tests/selenium/specs/page.js (1 retries)
[0-1] 2022-05-20T22:16:39.065Z ERROR @wdio/runner: Error: connect ECONNREFUSED 127.0.0.1:58169
[0-1] at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1148:16)
[0-2] FAILED in chrome - /tests/selenium/specs/user.js (1 retries)
[0-3] FAILED in chrome - /tests/selenium/specs/watchlist.js (1 retries)
[0-1] FAILED in chrome - /tests/selenium/specs/recentchanges.js (1 retries)
[0-4] RUNNING in chrome - /tests/selenium/wdio-mediawiki/specs/BlankPage.js
[0-4] 2022-05-20T22:17:10.637Z ERROR @wdio/runner: Error: connect ECONNREFUSED 127.0.0.1:58063
[0-4] at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1148:16)
[0-4] RETRYING in chrome - /tests/selenium/wdio-mediawiki/specs/BlankPage.js
[0-4] RUNNING in chrome - /tests/selenium/wdio-mediawiki/specs/BlankPage.js
[0-4] 2022-05-20T22:17:42.220Z ERROR @wdio/runner: Error: connect ECONNREFUSED 127.0.0.1:57439
[0-4] at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1148:16)
[0-4] FAILED in chrome - /tests/selenium/wdio-mediawiki/specs/BlankPage.js (1 retries)
Spec Files: 0 passed, 5 retries, 5 failed, 5 total (100% completed) in 00:02:22
```
**What should have happened instead?**:
@zeljkofilipin Did the same steps on his Intel Mac and everything works ok.
I suspect there's some chromium configuration which isn't playing nice with arm64 hosts. If I understand correctly, since it doesn't look like we're building a fresh image for arm64, the amd64 image is used. My inclination was to see about building a fresh image for arm64, but I haven't tracked down specifics for how to go about this with fresh.
I know headless chrome can play nice on M1 from using browserless-chrome, which has an arm64 build:
https://hub.docker.com/r/browserless/chrome/tags
I'm using it elsewhere (though I do have an unrelated bug using it). Here's some info on what they use spinning up headless chrome:
https://docs.browserless.io/blog/2018/06/04/puppeteer-best-practices.html#7-use-docker-to-contain-it-all
**Software version (if not a Wikimedia wiki), browser information, screenshots, other information, etc.**:
- MacOS Monterey 12.3.1
- Apple M1
- Docker Desktop 4.8.2, Engine 20.10.14, Compose 2.5.1
Any help is appreciated. I may be missing something glaringly obvious...
----
#upstream issue https://github.com/docker/for-mac/issues/5766 got declined
> Closing as documented. https://docs.docker.com/docker-for-mac/apple-silicon/#known-issues
>
> We don't have control over qemu and it's "best effort" only. We have documented both the occasional crashes and the lack of inotify support.
https://docs.docker.com/desktop/troubleshoot/known-issues/ and hitting {nav For Mac with Apple Silicon} has a list of issues including:
> Some images do not support the ARM64 architecture. You can add `--platform linux/amd64` to run (or build) an Intel image using emulation.
> However, attempts to run Intel-based containers on Apple silicon machines under emulation can crash as qemu sometimes fails to run the container. In addition, filesystem change notification APIs (`inotify`) **do not work under qemu emulation**. Even when the containers do run correctly under emulation, they will be slower and use more memory than the native equivalent.
> In summary, running Intel-based containers on Arm-based machines should be regarded as "best effort" only. We recommend running arm64 containers on Apple silicon machines whenever possible, and encouraging container authors to produce arm64, or multi-arch, versions of their containers.
There is also https://gitlab.com/qemu-project/qemu/-/issues/324 //chrome based apps can not be run under qemu user mode// which refers to a patch which theoretically can be applied to the QEmu Debian package to see whether it improves things and then find a way to commit time to review/test it in order to get the patch merged by upstream. That needs some commitment and knowledge about system calls / OS development.