karma-firefox-launcher: Firefox 68.x won't run (from inside docker)

I’ve used FirefoxHeadless inside docker just fine for a long time - but with v68 of ffox it just won’t work.

19:02:46 09 08 2019 17:02:44.991:INFO [launcher]: Starting browser FirefoxHeadless
19:03:54 09 08 2019 17:03:45.123:WARN [launcher]: FirefoxHeadless have not captured in 60000 ms, killing.
19:03:54 09 08 2019 17:03:45.598:INFO [launcher]: Trying to start FirefoxHeadless again (1/2).
19:04:54 09 08 2019 17:04:45.602:WARN [launcher]: FirefoxHeadless have not captured in 60000 ms, killing.
19:04:54 09 08 2019 17:04:45.724:INFO [launcher]: Trying to start FirefoxHeadless again (2/2).
19:05:50 09 08 2019 17:05:45.855:WARN [launcher]: FirefoxHeadless have not captured in 60000 ms, killing.
19:05:50 09 08 2019 17:05:47.109:ERROR [launcher]: FirefoxHeadless failed 2 times (timeout). Giving up.

Karma config:

// Karma configuration file, see link for more information
// https://karma-runner.github.io/0.13/config/configuration-file.html

//https://hackernoon.com/running-karma-tests-with-headless-chrome-inside-docker-ae4aceb06ed3
const isDocker = require('is-docker')();


module.exports = function (config) {
  config.set({
    concurrency: 1, // avoid clash when ffox and chrome run at the same time
    customLaunchers: {
      ChromeCustom: {
        base: 'ChromeHeadless',
        // We must disable the Chrome sandbox when running Chrome inside Docker (Chrome's sandbox needs
        // more permissions than Docker allows by default)
        flags: isDocker ? ['--no-sandbox'] : []
      }
    },
    basePath: '',
    frameworks: ['jasmine', '@angular-devkit/build-angular'],
    plugins: [
      require('karma-jasmine'),
      require('karma-coverage'),
      require('karma-coverage-istanbul-reporter'),
      require('karma-chrome-launcher'),
      require('karma-firefox-launcher'),
      require('karma-junit-reporter'),
      //require('karma-remap-istanbul'),
      require('@angular-devkit/build-angular/plugins/karma')
    ],
    files: [
    ],
    preprocessors: {
      './src/app/**/*.ts': ['coverage']
    },
    coverageReporter: {
      type:'lcov',
      dir:'target/coverage'
    },
    mime: {
      'text/x-typescript': ['ts','tsx']
    },
    angularCli: {
      config: './angular-cli.json',
      environment: 'dev'
    },
    reporters: config.angularCli && config.angularCli.codeCoverage
              ? ['progress', 'junit','coverage-istanbul','coverage']
              : ['progress', 'junit'],
    junitReporter: {
      outputDir: 'target/junit-reports'
      //outputDir: 'target/junit-dir: require('path').join(__dirname, 'coverage'), reports'
    },
    port: 9876,
    colors: true,
    autoWatch: true,
    browsers: ['FirefoxHeadless','ChromeCustom'],
    singleRun: false
  });
};

Image I am using: https://hub.docker.com/r/evryfs/node-dev-docker/ (node12 tag)

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Comments: 49

Commits related to this issue

Most upvoted comments

Facing the same problem with gitlab-ci using firefox-esr 68 from debian buster.

Setting MOZ_FORCE_DISABLE_E10S=true made things work again.

I am also seeing this:

16 08 2019 08:01:24.483:INFO [launcher]: Starting browser FirefoxHeadless

16 08 2019 08:04:51.187:ERROR [launcher]: Cannot start FirefoxHeadless

	*** You are running in headless mode.

[Parent 134, Gecko_IOThread] WARNING: pipe error: Broken pipe: file /builds/worker/workspace/build/src/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 727

Oh, that’s super helpful. So know we now that at least it is finding the binary.

Digging into related issues, this seems really promising:

Specifically, it points to problems with shared memory affecting firefox running in docker containers and includes:

Why did this happen in the move from FF 67 to FF 68? Because I did disable SHM usage in FF by disabling E10s using user_pref(“browser.tabs.remote.autostart”, false);, but as this bug (https://bugzilla.mozilla.org/show_bug.cgi?id=1548941) says, support for this flag was removed in FF 68.

karma-firefox-launcher likewise includes user_pref("browser.tabs.remote.autostart", false) (and user_pref("browser.tabs.remote.autostart.2", false)).

The solution seems to be running docker with --shm-size 2g or mounting -v /dev/shm:/dev/shm.

See:

Ultimately, though it seems like this is tracked by:

I haven’t heard of any new reports of this and various fixes have landed in Firefox as mentioned by @gcp (notably bug 1440203 in Firefox 84 and also bug 1582954 in Firefox 80). Those fixes should now be in Firefox ESR 91 and 102 too so I’m closing this for now.

Comment 22 in particular suggested the handling there may change.

Yes, anything can change but that won’t help Firefox 68.x -> 72.x who allocate shared memory in the way a Linux application should, i.e. by using shmem_open() which will create a mapping in /dev/shm.

jld told me he’s restarting memfd_create() work, so I’ll hold off to see if we can get that working (Chromium seems to have given up on it, hmmm…).

But again, as long as docker/kubernetes misconfigure /dev/shm, it’s going to be misery for applications that use shared memory. The fix here is to fix the misconfiguration, not hope that a potential Firefox change ends up working around the brokenness.

If it is working with xvfb but not headless then this is likely a headless widget issue, probably accidentally depending on a windowing system existing somwhere. @brendandahl might have ideas.

@birtles but why does it work fine outside of docker on my Mac?

Inside docker you have no windowing system and are presumably running the linux version of Firefox. Outside you have a windowing system and are running the osx version. Those are two very different situations.