restore references to browserview in docs, but replaced with references to webcontentsview

This commit is contained in:
Jeremy Rose
2022-09-14 15:05:01 -07:00
parent f0ceb6ed6d
commit ac4c0b2f0f
3 changed files with 30 additions and 11 deletions

View File

@@ -4,9 +4,10 @@
Electron's `webview` tag is based on [Chromium's `webview`][chrome-webview], which
is undergoing dramatic architectural changes. This impacts the stability of `webviews`,
including rendering, navigation, and event routing. We currently recommend to not
use the `webview` tag and to consider alternatives, like `iframe` or an
architecture that avoids embedded content altogether.
including rendering, navigation, and event routing. We currently recommend to
not use the `webview` tag and to consider alternatives, like `iframe`, a
[`WebContentsView`](web-contents-view.md), or an architecture that avoids
embedded content altogether.
## Enabling

View File

@@ -79,8 +79,8 @@ will be able to execute native code on the user's machine.
Under no circumstances should you load and execute remote code with
Node.js integration enabled. Instead, use only local files (packaged together
with your application) to execute Node.js code. To display remote content, use
the [`<webview>`][webview-tag] tag and make sure to disable the
`nodeIntegration` and enable `contextIsolation`.
the [`<webview>`][webview-tag] tag or a [`WebContentsView`][web-contents-view]
and make sure to disable the `nodeIntegration` and enable `contextIsolation`.
:::
:::info Electron security warnings
@@ -167,10 +167,11 @@ This recommendation is the default behavior in Electron since 5.0.0.
:::
It is paramount that you do not enable Node.js integration in any renderer
([`BrowserWindow`][browser-window] or [`<webview>`][webview-tag]) that loads
remote content. The goal is to limit the powers you grant to remote content,
thus making it dramatically more difficult for an attacker to harm your users
should they gain the ability to execute JavaScript on your website.
([`BrowserWindow`][browser-window], [`WebContentsView`][web-contents-view], or
[`<webview>`][webview-tag]) that loads remote content. The goal is to limit the
powers you grant to remote content, thus making it dramatically more difficult
for an attacker to harm your users should they gain the ability to execute
JavaScript on your website.
After this, you can grant additional permissions for specific hosts. For example,
if you are opening a BrowserWindow pointed at `https://example.com/`, you can
@@ -305,8 +306,9 @@ This recommendation is Electron's default.
:::
You may have already guessed that disabling the `webSecurity` property on a
renderer process ([`BrowserWindow`][browser-window], or
[`<webview>`][webview-tag]) disables crucial security features.
renderer process ([`BrowserWindow`][browser-window],
[`WebContentsView`][web-contents-view], or [`<webview>`][webview-tag]) disables
crucial security features.
Do not disable `webSecurity` in production applications.
@@ -760,6 +762,8 @@ function validateSender(frame) {
[breaking-changes]: ../breaking-changes.md
[browser-window]: ../api/browser-window.md
[webview-tag]: ../api/webview-tag.md
[web-contents-view]: ../api/web-contents-view.md
[responsible-disclosure]: https://en.wikipedia.org/wiki/Responsible_disclosure
[web-contents]: ../api/web-contents.md
[window-open-handler]: ../api/web-contents.md#contentssetwindowopenhandlerhandler
[will-navigate]: ../api/web-contents.md#event-will-navigate

View File

@@ -41,3 +41,17 @@ communication with the `<webview>` is done asynchronously using IPC. The
Compared to an `<iframe>`, `<webview>` tends to be slightly slower but offers
much greater control in loading and communicating with the third-party content
and handling various events.
### WebContentsView
[`WebContentsView`](../api/web-contents-view.md)s are not a part of the DOM -
instead, they are created in and controlled by your Main process. They are
simply another layer of web content on top of your existing window. This means
that they are completely separate from your own `BrowserWindow` content and
their position is not controlled by the DOM or CSS. Instead, it is controlled
by setting the bounds in the Main process.
`WebContentsView`s offer the greatest control over their contents, since they
implement the `webContents` similarly to how the `BrowserWindow` does it.
However, as `WebContentsView`s are not a part of your DOM, but are rather
overlaid on top of them, you will have to manage their position manually.