Explore replacing <webview> with WebContentsView #78
Description
The use of <webview> has been discouraged for years, and is quite flaky, but was the only way to really build what we needed to build in Shell.
The new WebContentsView which replaces BrowserView may offer an alternative, but is very different.
Rather than being an HTML element in the DOM in the renderer process which can be positioned with CSS, a WebContentsView is created in the main process and has to be positioned in JavaScript. This means leaving a placeholder in the browser chrome and then syncing the position of the WebContentsView with that element using IPC messages.
Possibly the biggest challenge is that it's not possible for HTML in a <webview> to overlap web content rendered in a WebContentsView. This means that UI elements like the site info menu used for pinning apps could not be part of the DOM in the renderer process, but would have to be part of another WebContentsView in the main process which overlaps the one displaying the web page (they are displayed in the order they are added). This could be a separate menuView which is overlayed on top and only displayed when needed.
This would significantly complicate the architecture of Shell because lots more things would need to be communicated over IPC and the position of views would have to be kept in sync, but could bring significant performance, stability and security improvements as it is closer to how native web browsers work (the underlying system behind is no longer used by Chromium-based browsers and doesn't work brilliantly).