Running Firefox in headless mode on Windows container with windows/servercore

Question

In order to supply Windows Selenium WebDriver Grid, I started preparation of Dockerfile that would allow to serve as grid node. The original cause was to prepare an image with controllable Firefox/GeckoDriver version. Encouraged by the successful preparation of the Chrome image with the same purpose in mind, I started with the following Dockerfile:

FROM mcr.microsoft.com/windows/servercore:1809

# Install chocolatey
RUN @"%SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe" -NoProfile -InputFormat None -ExecutionPolicy Bypass -Command "iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))" && SET "PATH=%PATH%;%ALLUSERSPROFILE%\chocolatey\bin"
RUN choco feature enable -n allowGlobalConfirmation

WORKDIR C:\\tools

# Set driver/browser versions
ARG Selenium_Major_Version="3.141"
ARG Selenium_Version="3.141.59"

ARG GeckoDriver_Version="0.24.0"
ARG Firefox_Version="66.0.3"

# Install Java
RUN choco install jdk8

# Download Selenium
RUN powershell Invoke-WebRequest \
    -Uri "https://selenium-release.storage.googleapis.com/$env:Selenium_Major_Version/selenium-server-standalone-$env:Selenium_Version.jar" \
    -OutFile ".\\selenium-server-standalone.jar"

# Install Firefox
RUN choco install firefox --version %Firefox_Version%

COPY config.json .

ENTRYPOINT java \
    -Dwebdriver.gecko.driver=C:\\tools\\geckodriver.exe \
    -jar selenium-server-standalone.jar \
    -role node \
    -nodeConfig config.json

Now, once container is started, the response from spawned geckodriver in WebDriver (executed with logs on TRACE level) hangs at:

node_1  | 1555088898615 mozrunner::runner       INFO    Running command: "C:\\Program Files\\Mozilla Firefox\\firefox.exe" "-marionette" "--headless" "-foreground" "-no-remote" "-profile" "C:\\Users\\ContainerAdministrator\\AppData\\Local\\Temp\\rust_mozprofile.SfT4FwVW8T8s"
node_1  | 1555088898631 geckodriver::marionette DEBUG   Waiting 60s to connect to browser on 127.0.0.1:49171
node_1  | 1555088959727 mozrunner::runner       DEBUG   Killing process 1252
node_1  | 1555088959727 webdriver::server       DEBUG   <- 500 Internal Server Error {"value":{"error":"unknown error","message":"connection refused","stacktrace":""}}

So it's a matter of Firefox being not launched correctly since GeckoDriver was able to spawn it but not interact with it. Moreover, running firefox.exe directly in the container causes firefox.exe process to appear once the tasklist is executed, but it's just one process taking 6MB of RAM (unlike Chrome, which spawn dozens of processes and has no problem in running headlessly, same for the Firefox executed on Windows 10). I assume that there's some kind of an obstacle that prevents Firefox from being opened and since Server Core has no GUI, it cannot be displayed and cannot be diagnosed. Sadly, I haven't found any information about Firefox logs stored on disk or run Firefox in more verbose mode from command line. The things I already tried:

• change Firefox to 32-bit
• various Firefox versions
• Install subset of DirectX
• Install Firefox without chocolatey
• various Windows Server Core versions

To sum up, even if it's not possible (but why? It was possible with Chrome), I'd like to know what's the actual error and what's the reason of failure. More verbose info from the Firefox itself would be handy as well.

I know that the easiest way to do it would be to switch to Linux, but long story short, it's not possible at the moment.

Versions:

• Docker: 18.09.2, build 6247962
• Firefox: 66.0.3
• GeckoDriver: 0.24.0

Answer 1

I think you are exhausting your shared memory (did not see how you run your docker, but guessing). The issue is that geckodriver clogs the share memory. The reasons have not been fully understood yet yet. You have two options. Mount the share memory or set fixed size.

If you want to set a fix size you do it with the --shm-size (shared memory size) switch. You have to set it to at least ShmSize: 1800000000 (1.8g). Usually for simplicity it is set to 2G:

--shm-size 2g

If you check the github docs running images you can even see this warning:

❗️ When executing docker run for an image with Chrome or Firefox please either mount -v /dev/shm:/dev/shm or use the flag --shm-size=2g to use the host's shared memory.

For Firefox it would be:

$ docker run -d -p 4444:4444 -v /dev/shm:/dev/shm selenium/standalone-firefox:3.141.59-mercury
OR
$ docker run -d -p 4444:4444 --shm-size 2g selenium/standalone-firefox:3.141.59-mercury

Some have reported that even raising the limit did not help. If that would be your case you can hack the about:config

To quote:

I've been able to work around this issue by closing tabs before quitting out the main tab. Also setting the URL to about:config/blank before closing,

while (this.WindowHandles.Count > 1)
{
    this.Navigate().GoToUrl("about:config");
    this.Navigate().GoToUrl("about:blank");
    this.Close(); //Close Tab
    this.SwitchTo().Window(this.WindowHandles.Last());
}
this.Navigate().GoToUrl("about:config");
this.Navigate().GoToUrl("about:blank");
this.Quit(); //Then main window