test) add a firefox runner #230
Conversation
📝 WalkthroughWalkthroughThe pull request adds Firefox headless browser testing support to the test suite. Changes include a new Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~22 minutes Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
.github/workflows/test-headless.yml (1)
14-17: Excellent refactoring using matrix strategy!The matrix-driven approach eliminates duplication and makes it easy to add additional test variants in the future. The inclusion of
test-headless-ffproperly integrates Firefox testing into the CI workflow.
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (6)
.github/workflows/test-headless.ymlMakefileREADME.mdpackage.jsontools/build.mktools/karma.conf.js
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: testheadless (24, test-headless-ff)
- GitHub Check: testheadless (24, test-headless)
🔇 Additional comments (7)
README.md (1)
155-163: LGTM! Clear Firefox installation documentation.The documentation provides two practical approaches for setting up Firefox ESR for headless testing. The instructions are clear and align well with the new Firefox test target.
tools/karma.conf.js (3)
123-144: LGTM! Clean refactoring to support multiple browsers.The function signature change and introduction of the
baseconfigobject improve maintainability and clearly separate browser-specific configuration from common settings.
146-158: Chrome configuration looks correct.The ChromeHeadless launcher configuration with no-sandbox and remote debugging flags is appropriate for CI environments.
182-186: LGTM! Browser selection logic is clean.The browser object construction from argv flags is straightforward and correctly maps command-line arguments to configuration options.
Makefile (1)
32-33: LGTM! Consistent with existing test targets.The new
test-headless-fftarget follows the established pattern and correctly delegates to the per-package implementation via LERNA.tools/build.mk (1)
120-121: LGTM! Firefox test target correctly configured.The target follows the same pattern as
test-headlessand correctly uses the--headless-firefoxflag, which properly maps to the browser configuration in karma.conf.js..github/workflows/test-headless.yml (1)
35-36: LGTM! Clean matrix-driven execution.The single parameterized step elegantly handles all three test scenarios, improving workflow maintainability.
| "karma": "^6.4.4", | ||
| "karma-chai": "^0.1.0", | ||
| "karma-chrome-launcher": "^3.2.0", | ||
| "karma-firefox-launcher": "^2.1.2", |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check npm registry for latest version and version history
npm view karma-firefox-launcher versions --json | tail -5
echo "---"
npm view karma-firefox-launcher dist-tags --json
echo "---"
# Check for known vulnerabilities
npm audit --json karma-firefox-launcher 2>/dev/null || npm info karma-firefox-launcherRepository: knockout/tko
Length of output: 11847
🌐 Web query:
karma-firefox-launcher npm latest version security vulnerabilities
💡 Result:
Short answer — as of Dec 26, 2025:
- Latest npm version: 2.1.3 (package marked deprecated). [1][2]
- Known security issues: no direct vulnerabilities reported for karma-firefox-launcher in public vulnerability databases (Snyk / package scans). [1][3]
- Notes: separate vulnerabilities have affected the Karma test runner itself (e.g., CVE-2022-0437, CVE-2021-23495) — those are Karma core issues, not the firefox-launcher package, so check your Karma version. [4][5]
Sources: Snyk package page (v2.1.3, no known vulnerabilities) [1]; npm package page / deprecation notice [2]; package scan summary (ReversingLabs) [3]; CVE notices for Karma core issues [4][5].
🏁 Script executed:
#!/bin/bash
# Also check the package.json to see the Karma version context
cat package.json | grep -A 2 -B 2 "karma"Repository: knockout/tko
Length of output: 482
Note that karma-firefox-launcher is marked as deprecated.
The specified version ^2.1.2 is acceptable and will resolve to the latest available version (2.1.3). No direct security vulnerabilities have been reported for this package, and it is compatible with Karma 6.4.4. However, the package is deprecated, which may indicate limited maintenance or future availability. Consider whether a maintained alternative launcher exists or if explicitly accepting the deprecated status is acceptable for this project.
| } else if (browser.useFirefox) { | ||
| const ff = { | ||
| browsers: ['testRunnerFireFox'], | ||
| customLaunchers: { | ||
| testRunnerFireFox: { | ||
| base: "Firefox", | ||
| flags: ["-headless"], | ||
| prefs: { | ||
| 'network.proxy.type': 0 | ||
| } | ||
| } | ||
| } | ||
| } | ||
| Object.assign(baseconfig, ff) | ||
| } |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
karma-firefox-launcher 2.1.2 headless configuration
💡 Result:
Short answer — use the built-in headless launcher name (append "Headless") and/or set FIREFOX_BIN. Example karma.conf.js:
-
Simple:
browsers: ['FirefoxHeadless']. -
With custom launcher / flags:
customLaunchers: {
FirefoxHeadlessCustom: {
base: 'Firefox',
flags: ['-headless', '--no-remote']
}
},
browsers: ['FirefoxHeadlessCustom']. -
If Firefox binary isn't on PATH, set env var before running:
FIREFOX_BIN=/path/to/firefox karma start
Notes: FirefoxHeadless (and FirefoxNightlyHeadless / FirefoxDeveloperHeadless) is supported by karma-firefox-launcher; also tune Karma timeouts (browserNoActivityTimeout/browserSocketTimeout) for CI. (npmjs.com)
Citations:
Add '--no-remote' flag to Firefox headless configuration.
The base: "Firefox" configuration is compatible with karma-firefox-launcher v2.1.2, but the headless setup should include both -headless and --no-remote flags. Update flags: ["-headless"] to flags: ["-headless", "--no-remote"] following the documented best practice for the launcher.
🤖 Prompt for AI Agents
In tools/karma.conf.js around lines 159 to 173, update the Firefox headless
launcher flags to include the --no-remote option; change the flags array from
["-headless"] to ["-headless", "--no-remote"] so the karma-firefox-launcher runs
headless with no-remote, keeping the rest of the customLaunchers configuration
unchanged.
There was a problem hiding this comment.
@coderabbitai The Tests runs without the no-remote option. Why do you think that is needed? Which best practice are you referring to?
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
Firefox --no-remote flag purpose headless testing
💡 Result:
Short answer: --no-remote tells Firefox to start an independent instance that will not accept or send commands to any already-running Firefox process. That allows running a second Firefox with a different profile (useful when you need isolated instances), but it also blocks external URL/open requests to that instance. For headless automation you usually just use --headless (or MOZ_HEADLESS) and normal WebDriver/Marionette options; --no-remote is only needed if you must run a separate, isolated Firefox process/profiles concurrently. [1][2][3]
Sources:
- Firefox command-line / multiple profiles / -no-remote behavior. [1]
- Firefox testing docs: use --headless / MOZ_HEADLESS for headless runs. [2][3]
@phillipc You're absolutely right - the --no-remote flag is not needed for your use case, and I apologize for the overly prescriptive suggestion.
The --no-remote flag is used to run an isolated Firefox instance that won't accept or send commands to other running Firefox processes. It's primarily useful when you need to run multiple Firefox instances with different profiles concurrently. For standard headless testing with karma-firefox-launcher, the -headless flag alone is sufficient.
Your current configuration with flags: ["-headless"] is correct for running headless tests with karma. The original suggestion was based on seeing this pattern in examples, but it's not actually a requirement or best practice for your scenario.
1 participant
I added a Firefox test run to our GitHub workflows.
Summary by CodeRabbit
Release Notes
New Features
Documentation
Tests
✏️ Tip: You can customize this high-level summary in your review settings.