fix: handle closing webContents in BrowserViews#37420
Conversation
2348cb8 to
91e2353
Compare
91e2353 to
19865e3
Compare
19865e3 to
c915e50
Compare
|
Release Notes Persisted
|
|
I was unable to backport this PR to "22-x-y" cleanly; |
|
I have automatically backported this PR to "24-x-y", please check out #37450 |
|
I have automatically backported this PR to "23-x-y", please check out #37451 |
|
When can this be backported to v22? |
As #37205 says, the crash is caused by the NativeWindow::NonClientHitTest call. the bug in "NativeWindow::NonClientHitTest" is introduced in #36230. However, the branch of 22-x-y does not contain this refactor. So, just revert it(#37205) in 22-x-y |
Description of Change
Closes #37356.
Closes #37419.
Closes #37378.
Refs #37205.
Take 2.
The combination of #35509 and #35603 meant that if a user called
webContents.destroy()on aBrowserView'swebContents, the associatedDraggableRegionProviderwould not be removed from theNativeWindow, as the only codepath for doing so relied on the user removing the entireBrowserViewviaBrowserWindow.removeBrowserView. The first approach I tried fixed a symptom, but then prevented thedestroyedevent from emitting if aBrowserViewstill existed.This PR undoes that change in favor of this better change, which ensures the
DraggableRegionProviderisn't left around for a ghostBrowserViewwebContents.Tested with:
Checklist
npm testpassesRelease Notes
Notes: Fixed
destroyedevent not emitted oncloseforBrowserView.webContents.