Electron Releases

Description of Change

Fixes #52141 (the crash cases > "promise-destroy-crash" flake on Windows), which turned out to be a real quit hang rather than a test problem.

• shell.openExternal() / shell.openPath() / shell.showItemInFolder() post their ShellExecuteEx() work to a COM STA thread-pool task with the default SKIP_ON_SHUTDOWN behaviour. A SKIP_ON_SHUTDOWN task that has already started blocks ThreadPoolInstance::Shutdown(), and ShellExecuteEx() can block inside the OS for as long as Windows is showing UI for the request — e.g. the "you'll need a new app to open this link" dialog for a scheme with no registered handler (its helper thread sits in a synchronous cross-process COM release into OpenWith.exe until the dialog is dismissed). Net effect: app.quit() fires will-quit/quit, then the browser main thread parks in TaskTracker::CompleteShutdown() and the process never exits until the user clicks OK.
• Post these tasks with CONTINUE_ON_SHUTDOWN instead. This matches Chrome's platform_util::OpenItem, which uses that trait for exactly this reason ("can hang shutdown without this trait as it may result in an interactive dialog"). The tasks only touch their bound arguments and OS APIs, so letting shutdown proceed while one is still blocked in the shell is safe.

Verified on Windows CI by looping the promise-destroy-crash fixture with native stack capture on hang: current behaviour hung 132/243 runs (main thread in TaskTracker::CompleteShutdown, worker in ShellExecuteExW → CShellExecute::_RunThreadMaybeWait, shell helper thread in combase!RemoteReleaseRifRef); with this change 0/243.

Checklist

• PR description included and stakeholders cc'd
• npm test passes
• PR release notes describe the change in a way relevant to app developers, and are capitalized, punctuated, and past tense.

Release Notes

Notes: Fixed an issue on Windows where the app process could fail to exit after app.quit() while a shell.openExternal() or shell.openPath() call was still waiting on a system "Open with" dialog.