Docker Container Browser Fails to Launch

Libraries Browser
1

Getting started with the Browser library and the Docker image to get some automation configured for a CI workflow.

When testing locally and launching the command like this: docker run --volume $(pwd)/logs/:/app/logs --env-file .env --ipc=host --user pwuser --security-opt seccomp=seccomp_profile.json --platform linux/amd64 test_automation:rf_browser bash -c "robot --outputdir logs ui_tests"

I see this as a response:
[ WARN ] Keyword 'Take Screenshot fail-screenshot-{index}' could not be run on failure: Error: Tried to take screenshot, but no page was open. | FAIL | Error: browserType.launch: Browser closed. ==================== Browser output: ==================== <launching> /home/pwuser/.local/lib/python3.8/site-packages/Browser/wrapper/node_modules/playwright-core/.local-browsers/chromium-1028/chrome-linux/chrome --disable-field-trial-config --disable-background-networking --enable-features=NetworkService,NetworkServiceInProcess --disable-background-timer-throttling --disable-backgrounding-occluded-windows --disable-back-forward-cache --disable-breakpad --disable-client-side-phishing-detection --disable-component-extensions-with-background-pages --disable-default-apps --disable-dev-shm-usage --disable-extensions --disable-features=ImprovedCookieControls,LazyFrameLoading,GlobalMediaControls,DestroyProfileOnBrowserClose,MediaRouter,DialMediaRouteProvider,AcceptCHFrame,AutoExpandDetailsElement,CertificateTransparencyComponentUpdater,AvoidUnnecessaryBeforeUnloadCheckSync,Translate --allow-pre-commit-input --disable-hang-monitor --disable-ipc-flooding-protection --disable-popup-blocking --disable-prompt-on-repost --disable-renderer-backgrounding --disable-sync --force-color-profile=srgb --metrics-recording-only --no-first-run --enable-automation --password-store=basic --use-mock-keychain --no-service-autorun --export-tagged-pdf --headless --hide-scrollbars --mute-audio --blink-settings=primaryHoverType=2,availableHoverTypes=2,primaryPointerType=4,availablePointerTypes=4 --no-sandbox --user-data-dir=/tmp/playwright_chromiumdev_profile-Kz7qkk... [ Message content over the limit has been removed. ] [pid=195][err] #13 0x0040037591e3 ChromeMain [pid=195][err] #14 0x00401014e083 __libc_start_main [pid=195][err] #15 0x00400375902a _start [pid=195][err] [pid=195][err] qemu: uncaught target signal 5 (Trace/breakpoint trap) - core dumped [pid=195][err] qemu: uncaught target signal 5 (Trace/breakpoint trap) - core dumped [pid=195][err] Received signal 11 SEGV_MAPERR 30303020702d35 [pid=195][err] #0 0x00400769f342 base::debug::CollectStackTrace() [pid=195][err] #1 0x0040076104f3 base::debug::StackTrace::StackTrace() [pid=195][err] #2 0x00400769ee61 base::debug::(anonymous namespace)::StackDumpSignalHandler() [pid=195][err] #3 0x00400f42a420 <unknown> [pid=195][err] #4 0x0040087b5838 FcStrSerializeAlloc [pid=195][err] #5 0x0040087a3fae FcDirCacheBuild [pid=195][err] #6 0x0040087a9b46 FcDirCacheScan [pid=195][err] #7 0x0040087a9bde IA__FcDirCacheRead [pid=195][err] #8 0x00400879fa27 FcConfigAddDirList [pid=195][err] #9 0x00400879f972 IA__FcConf
When I execute the same tests without the docker image (robot --outputdir logs ui_tests/), I do not encounter this issue.

2

Adding in that I’m seeing this on a M2 MacBook Pro.

3

You may need to “rebuild” the image if they do not support arm architectures.
Selenium had a similar issue. They only had linux/amd64 images, so I built my own image on my m1 Mac for selenium (although now they have an experimental image for arm.)

4

Adding an update here.

I’ve had some conversation about this issue in the Slack channel and tried out the suggestions from there and here.

I’m now using the --platform=x86_64 param in both the build and the run command. That still leads to the same error shown in the original description.

Checking out the linked thread mentioned in the Slack thread, I see the same AMD64 alert in Docker Desktop. I’ve attempted building my own browser image. That raised a separate error. I’ve merged in the Dockerfile commands to my own Dockerfile and end up with the same error message as shown in the original forum post.

In the meantime, I’m going to try checking for a linux device I can use to test if this happens there. I want to narrow down to an M2 issue and not a PEBKAC issue. Or, if all goes well, this might be similar to what happened in the other Slack thread where the image was building successfully but could not be run on the M1 device.