#54558: refactor: give WebContentsView a native view of its own
Description of Change
A WebContentsView used its webContents InspectableWebContentsView as its native view. The webContents owns that view and deletes it along with itself, so a WebContentsView could outlive its native view and every View method had to check for a null view.
WebContentsViewHost now owns a container view for the whole life of the WebContentsView and presents the inspectable view in it, as its last child. Child views added from JavaScript stay before it and so beneath the page, as they were when added to the inspectable view. With that, View::Host always owns its view, and the unowned mode goes away.
Ownership of the webContents no longer needs a user-data claim. The host whose container presents the inspectable view owns it. Adopting a webContents in a new WebContentsView moves the inspectable view into the new container, so only that view acts on the webContents and destroys it when collected. Two WebContentsViews that share a webContents are now separate children, rather than one native view tracked twice.
Release Notes
Notes: none
Backports
No Backports Requested
This pull request doesn't have any backports requested or created for older release branches.
What are backports?
Backports are copies of changes made to the main branch that are applied to older release branches. They ensure that bug fixes and important changes are available in maintained older versions of Electron.
Semver Impact
Semantic Versioning helps users understand the impact of updates:
- Major (X.y.z): Breaking changes that may require code modifications
- Minor (x.Y.z): New features that maintain backward compatibility
- Patch (x.y.Z): Bug fixes that don't change the API
- None: Changes that don't affect using facing parts of Electron