← Back to microsoft/playwright
microsoft / playwright · Issue No. 40586
Is your feature request related to a problem?
electronApp.close() currently waits indefinitely for the Electron process to exit. If the application has before-quit handlers that prevent shutdown, leaky IPC handlers, or child processes that keep it alive, close() hangs forever until the test-level timeout kills everything.
This is a well-documented pain point:
app.quit() called but process sticks aroundPR #11336 rightfully removed the old hardcoded 30s timeout (which was inconsistent with other close() methods). But now there is no way for users to specify a grace period with force-kill escalation.
The force-kill infrastructure already exists in processLauncher.ts (killProcess() → SIGKILL / taskkill /T /F) but is only reachable via OS signals (SIGINT/SIGTERM), not through the public close() API.
Describe the solution
Add an opt-in timeout option to electronApp.close():
// Default: wait forever (unchanged behavior)
await electronApp.close();
// With timeout: force-kill if app does not exit within 10s
await electronApp.close({ timeout: 10_000 });
When specified:
browser.close() → app.quit() → worker._disconnect())kill() from processLauncher (SIGKILL/taskkill)This is different from the removed behavior (#11336) because:
kill function from launchProcess into ElectronApplicationReal-world use case
We maintain E2E tests for a VS Code extension using Playwright Electron. Our test teardown was flaky because close() would occasionally hang when the Electron app did not exit cleanly. We had to build a 3-layer workaround: app.quit() → app.close() wrapped in Promise.race with manual timer → SIGKILL fallback. This feature would replace that pattern with a single API call.
I have a PR ready if you are open to this.
Relay reads this issue against the repository's contribution signals: the files it is likely to touch, how the maintainers triage work this size, and what the first contribution would exercise.
The full analysis for this issue is still being assembled. Until then, the description above and the thread on GitHub are the most reliable context.