Question
ChromeHeadless Timeouts Across a Karma 6.x Upgrade: One Contract or Chrome-Version Dependent?
Sky Finch
0 reputation · 18 Jan 2026, 04:25 UTC
147K views
Loading…
0 reputation · 18 Jan 2026, 04:25 UTC
A Karma upgrade — assume a current 6.4.x server with a matching karma-chrome-launcher — sits on a moving target: the Chrome binary that ChromeHeadless drives. Karma documents browserNoActivityTimeout, browserDisconnectTimeout and captureTimeout as settings in karma.conf.js, but it is unclear whether their enforcement stays uniform when the browser version changes underneath.
The stakes are highest in CI setups that set singleRun: true and list ChromeHeadless alongside Firefox in the browsers array. If a Chrome version bump shifts launch, idle-reporting or shutdown timing, a suite could surface disconnects — or stall until an outer pipeline timeout fires — with no Karma configuration change. Plugin ordering is a separate documented cause of silent failures, so this question concerns only the timeout layer.
The goal is a precise ownership statement for each timer: which layer decides the effective deadline for a ChromeHeadless run, and how that changes across browser upgrades. This behavior is flagged as unsettled and should be verified per environment.
browserNoActivityTimeout and browserDisconnectTimeout enforced identically for ChromeHeadless regardless of the installed Chrome major version?singleRun, when a Chrome upgrade alters shutdown timing, which timer fires first, and is the outcome reported as a browser disconnect or a test timeout?A thoughtful contribution can make all the difference. Be the first to share one.
Use comments to ask for clarification. Post a solution as an answer.
6,300 reputation · 18 Jan 2026, 15:16 UTC
In Karma 6.x the browserNoActivityTimeout and browserDisconnectTimeout values are applied by Karma’s WebSocket logic. They do not change when the underlying Chrome binary is upgraded.
What can shift is Chrome’s exit delay. A newer Chrome may shut down headless faster or slower, which can cause Karma to report a WebSocket disconnect before the test suite finishes. In that case the disconnect timeout fires first, even though the test timeout has not yet elapsed.
Thus, the timeout thresholds are effectively unversioned; only Chrome’s shutdown timing can affect which event is logged first.
karma