ChromeHeadless Timeouts Across a Karma 6.x Upgrade: One Contract or Chrome-Version Dependent?

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.

1. Are browserNoActivityTimeout and browserDisconnectTimeout enforced identically for ChromeHeadless regardless of the installed Chrome major version?
2. Under 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?
3. Is there a documented Karma-to-Chrome compatibility boundary where timeout semantics changed, or is the behavior effectively unversioned?