github/electron
1
1
Fork 0
mirror of https://github.com/electron/electron.git synced 2026-04-10 03:01:51 -04:00
Code Issues Packages Projects Releases Wiki Activity

feat: replace BrowserView with WebContentsView (#40759)

Browse Source 
* feat: replace BrowserView with WebContentsView

Co-authored-by: Jeremy Rose <jeremya@chromium.org>

* Update appveyor.yml

---------

Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Jeremy Rose <jeremya@chromium.org>
This commit is contained in:
trop[bot]
2024-01-11 13:10:11 -05:00
committed by GitHub
parent c2524d762b
commit bd304f7c9d
75 changed files with 2985 additions and 1529 deletions
Download Patch File Download Diff File Expand all files Collapse all files

21
docs/tutorial/web-embeds.md
View File

@@ -42,16 +42,15 @@ 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.
### BrowserViews
### WebContentsView
[BrowserViews](../api/browser-view.md) 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`](../api/web-contents-view.md)s are not a part of the
DOM—instead, they are created, controlled, positioned, and sized by your
Main process. Using `WebContentsView`, you can combine and layer many pages
together in the same [`BaseWindow`](../api/base-window.md).
`BrowserViews` offer the greatest control over their contents, since they
implement the `webContents` similarly to how the `BrowserWindow` does it.
However, as `BrowserViews` are not a part of your DOM, but are rather overlaid
on top of them, you will have to manage their position manually.
`WebContentsView`s offer the greatest control over their contents, since they
implement the `webContents` similarly to how `BrowserWindow` does it. However,
as `WebContentsView`s are not elements inside the DOM, positioning them
accurately with respect to DOM content requires coordination between the
Main and Renderer processes.