mirror of
https://github.com/electron/electron.git
synced 2026-04-10 03:01:51 -04:00
restore references to browserview in docs, but replaced with references to webcontentsview
This commit is contained in:
@@ -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
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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.
|
||||
|
||||
Reference in New Issue
Block a user