Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly
Appearance settings

feat: add webContents.forcefullyCrashRenderer() to forcefully terminate a renderer process #25580

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 2 commits into from
Oct 2, 2020
Merged

feat: add webContents.forcefullyCrashRenderer() to forcefully terminate a renderer process #25580

merged 2 commits into from
Oct 2, 2020

Conversation

MarshallOfSound
Copy link
Member

@MarshallOfSound MarshallOfSound commented Sep 23, 2020 •
edited
Loading

Currently the only way to recover a hung renderer is to close the window or manually call kill ${webContents.getProcessId()} neither of which is ideal. This adds a simple new method that aligns with what Chrome does to make killing a webConents in a hung state super easy.

Notes: Added webContents.forcefullyCrashRenderer() to forcefully terminate a renderer process to assist with recovering a hung renderer.

@electron-cation electron-cation bot added the new-pr 🌱 PR opened recently label Sep 23, 2020
@electron-cation electron-cation bot removed the new-pr 🌱 PR opened recently label Sep 24, 2020
ckerr
ckerr reviewed Sep 24, 2020
View reviewed changes
shell/browser/api/electron_api_web_contents.cc Show resolved Hide resolved
docs/api/web-contents.md Outdated Show resolved Hide resolved
nornagon
nornagon approved these changes Sep 28, 2020
View reviewed changes
spec-main/api-web-contents-spec.ts Outdated Show resolved Hide resolved
spec-main/api-web-contents-spec.ts Outdated Show resolved Hide resolved
@MarshallOfSound MarshallOfSound changed the title feat: add webContents.crashProcess() to forcefully terminate a renderer process feat: add webContents.forcefullyCrashRenderer() to forcefully terminate a renderer process Oct 2, 2020
@MarshallOfSound MarshallOfSound merged commit a189dc7 into master Oct 2, 2020
@release-clerk
Copy link

release-clerk bot commented Oct 2, 2020

Release Notes Persisted

Added webContents.forcefullyCrashRenderer() to forcefully terminate a renderer process to assist with recovering a hung renderer.

@MarshallOfSound MarshallOfSound deleted the crash-wc branch October 2, 2020 21:50
@trop trop bot mentioned this pull request Oct 2, 2020
Merged
@trop
Copy link
Contributor

trop bot commented Oct 2, 2020

I have automatically backported this PR to "11-x-y", please check out #25756

@nornagon nornagon mentioned this pull request Oct 5, 2020
Merged
6 tasks
@bpasero
Copy link
Contributor

bpasero commented Dec 12, 2020

@MarshallOfSound may I ask how and when this method should be used? In VSCode we have always been listening to the render-process-gone and unresponsive event where we show the user a dialog offering to either "Reload" or "Close" the window. When the user picks "Reload", we do an attempt to set a new URL to the window and for the "Close" case, we actually call BrowserWindow.destroy().

image

I am trying to understand if I should now use webContents.forcefullyCrashRenderer in any of these cases to increase the chances of getting "Reload" or "Close" to work as advertised?

//cc @deepak1556

@deepak1556
Copy link
Member

@bpasero this is useful in sandbox mode when a reload doesn't necessarily spawn a new process, where you can call this method and then reload to safely put the unresponsive webContents in a new process.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@ckerr ckerr ckerr left review comments

+1 more reviewer

@nornagon nornagon nornagon approved these changes

Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Labels

backport/approved ✅

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

5 participants

@MarshallOfSound @bpasero @deepak1556 @ckerr @nornagon
Morty Proxy This is a proxified and sanitized view of the page, visit original site.