Repository navigation
Restarting a local Chrome after a disconnect deadlocks for 30 s and then unregisters the relaunched browser when no window descriptor is cached #8562
Description
What is your Scenario?
A test blocks the page's main thread, so the browser stops answering heartbeats and TestCafe restarts it after the 2 minute heartbeat timeout. On a Linux desktop where find-window fails at browser start (TestCafe only warns and caches no window descriptor), the restart never works: closing the old headed Chrome deadlocks until BROWSER_CLOSE_TIMEOUT (30 s), the relaunched Chrome is then unregistered by that close when it finally finishes, and the run aborts.
Mechanism (from src/browser/provider/built-in/dedicated/chrome/index.js and src/browser/provider/index.ts): closeBrowser closes a headed Chrome through closeLocalBrowser, which first runs _ensureBrowserWindowDescriptor. With no descriptor cached that calls waitForConnectionReady, but a restarting connection is uninitialized until the relaunched browser connects, which only happens after this close has finished. After the 30 s limit _restartBrowser moves on and opens a new Chrome; the old close is still pending and later reaches delete this.openedBrowsers[browserId], removing the runtime info of the relaunched browser, whose setup then fails with a TypeError.
What is the Current behavior?
Timeline from DEBUG=testcafe:browser:* (times relative to the heartbeat expiry):
+0 s status changed to 'disconnected'
+30 s Error: A Promise timed out. (close of the old Chrome ran into BROWSER_CLOSE_TIMEOUT)
+30.6 s status changed to 'ready'
+30.7 s browser opened twHl4r4 (relaunched Chrome)
+35.6 s browser closed twHl4r4 (the old close finishes and deletes the new runtime info)
+35.6 s TypeError: Cannot read properties of undefined (reading 'windowDescriptors')
Test report:
Running tests in:
- Chrome 154.0.0.0 / Ubuntu 24.04
Blocked page
TypeError: Cannot read properties of undefined (reading 'windowDescriptors')
2/2 failed (2m 36s)
ERROR Unable to open the "chrome:" browser due to the following error:
TypeError: Cannot read properties of undefined (reading 'windowDescriptors')
Both tests are reported as failed and the run aborts; the second test never runs. The old Chrome window stays open.
What is the Expected behavior?
The old Chrome is closed promptly, the relaunched browser stays registered, and the test is retried in it as designed (and the following tests run).
What is the public URL of the test page? (attach your complete example)
hang.html:
<!doctype html>
<html><body>
<button id="hang" onclick="while (true) {}">Hang</button>
</body></html>What is your TestCafe test code?
fixture `Blocked page`
.page `./hang.html`;
test('Test that blocks the page', async t => {
await t.click('#hang');
});
test('Test after the blocked page', async () => {});Your complete configuration file
No configuration file.
Your complete test report
See above.
Screenshots
None.
Steps to Reproduce
- Use a Linux desktop where
find-windowfails (visible withDEBUG=testcafe:browser-tools:exec:Command failed: .../testcafe-browser-tools/bin/linux/glibc-64/find-window <id>, exit code 103, on Ubuntu 24.04 with GNOME here). - Save the two files above.
- Run
DEBUG=testcafe:browser:* testcafe chrome blocked-page-test.js(headed Chrome; headless Chrome closes through CDP and is not affected). - Wait for the heartbeat timeout (2 minutes).
TestCafe version
3.7.6
Node.js version
22.22.3
Command-line arguments
testcafe chrome blocked-page-test.js
Browser name(s) and version(s)
Google Chrome 154.0.8037.57 (headed)
Platform(s) and version(s)
Ubuntu 24.04.5 LTS
Other
I have a fix ready: a restarting close kills the Chrome process (as it already does for headless Chrome and on macOS) instead of closing the window, and a close that finishes after a relaunch no longer unregisters the new browser. I will open a PR referencing this issue.
Activity
Bayheck commentedon Oct 12, 2026
Hi @sam-yh,
Thank you for the detailed analysis and reproduction steps.
We checked this scenario. The issue occurs only under a rare combination of conditions: a test that blocks the page's main thread, a heartbeat timeout, a headed local Chrome, and an environment where TestCafe cannot find the browser window. We discussed this with the team and decided not to address this scenario at this time. We will leave the issue open in case other users encounter a similar issue.
Thank you for your understanding.