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.
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
fix: prevent crash if BrowserView webContents was destroyed #25112
Conversation
5d6c132
to
dda792a
Compare
1b75ab6
to
e13a519
Compare
No Release Notes |
I was unable to backport this PR to "10-x-y" cleanly; |
I was unable to backport this PR to "9-x-y" cleanly; |
I was unable to backport this PR to "8-x-y" cleanly; |
@codebytere has manually backported this PR to "10-x-y", please check out #25146 |
The change looks like a breaking change for me since some public methods got removed. How do I explicitly destroy the BrowserView instance in v11? Does the linked BrowserView isntance get automatically destroyed when I call |
@vladimiry this PR didn't remove the methods - it just addressed documentation as a follow-up on another PR which did so. However, we do agree with you - the PR which did remove these methods did not align with above stated goals as you point out and the methods will be restored. |
Thanks for clarification, I missed looking into that another PR. |
Description of Change
Fixes an issue where interacting with a BrowserWindow which had a BrowserView attached whose
webContents
had been destroyed could cause a crash inBaseWindow::ResetBrowserViews()
.cc @nornagon @MarshallOfSound
Checklist
npm test
passesRelease Notes
Notes: none.