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 [32m09 08 2019 17:02:44.991:INFO [launcher]: [39mStarting browser FirefoxHeadless
19:03:54 [33m09 08 2019 17:03:45.123:WARN [launcher]: [39mFirefoxHeadless have not captured in 60000 ms, killing.
19:03:54 [32m09 08 2019 17:03:45.598:INFO [launcher]: [39mTrying to start FirefoxHeadless again (1/2).
19:04:54 [33m09 08 2019 17:04:45.602:WARN [launcher]: [39mFirefoxHeadless have not captured in 60000 ms, killing.
19:04:54 [32m09 08 2019 17:04:45.724:INFO [launcher]: [39mTrying to start FirefoxHeadless again (2/2).
19:05:50 [33m09 08 2019 17:05:45.855:WARN [launcher]: [39mFirefoxHeadless have not captured in 60000 ms, killing.
19:05:50 [91m09 08 2019 17:05:47.109:ERROR [launcher]: [39mFirefoxHeadless 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
- Add env variable for Firefox Karma Firefox launcher ikssue: https://github.com/karma-runner/karma-firefox-launcher/issues/104 — committed to aduprat/esn-frontend-inbox by aduprat 4 years ago
- Add env variable for Firefox Karma Firefox launcher ikssue: https://github.com/karma-runner/karma-firefox-launcher/issues/104 — committed to aduprat/esn-frontend-inbox by aduprat 4 years ago
- Add env variable for Firefox Karma Firefox launcher ikssue: https://github.com/karma-runner/karma-firefox-launcher/issues/104 — committed to aduprat/esn-frontend-inbox by aduprat 4 years ago
- fix(dev-infra): karma firefox runner conf removed due to a known issue - see karma-runner/karma-firefox-launcher#104 — committed to cagcak/shopping-card by cagcak 3 years ago
Facing the same problem with gitlab-ci using firefox-esr 68 from debian buster.
Setting
MOZ_FORCE_DISABLE_E10S=truemade things work again.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:
karma-firefox-launcherlikewise includesuser_pref("browser.tabs.remote.autostart", false)(anduser_pref("browser.tabs.remote.autostart.2", false)).The solution seems to be running docker with
--shm-size 2gor 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.
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.
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.