Implement initial, experimental BrowserView API
Right now, `<webview>` is the only way to embed additional content in a
`BrowserWindow`. Unfortunately `<webview>` suffers from a [number of
problems](https://github.com/electron/electron/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20label%3Awebview%20).
To make matters worse, many of these are upstream Chromium bugs instead
of Electron-specific bugs.
For us at [Figma](https://www.figma.com), the main issue is very slow
performance.
Despite the upstream improvements to `<webview>` through the OOPIF work, it is
probable that there will continue to be `<webview>`-specific bugs in the
future.
Therefore, this introduces a `<webview>` alternative to called `BrowserView`,
which...
- is a thin wrapper around `api::WebContents` (so bugs in `BrowserView` will
likely also be bugs in `BrowserWindow` web contents)
- is instantiated in the main process like `BrowserWindow` (and unlike
`<webview>`, which lives in the DOM of a `BrowserWindow` web contents)
- needs to be added to a `BrowserWindow` to display something on the screen
This implements the most basic API. The API is expected to evolve and change in
the near future and has consequently been marked as experimental. Please do not
use this API in production unless you are prepared to deal with breaking
changes.
In the future, we will want to change the API to support multiple
`BrowserView`s per window. We will also want to consider z-ordering
auto-resizing, and possibly even nested views.
2017-04-11 17:47:30 +00:00
|
|
|
// Copyright (c) 2017 GitHub, Inc.
|
|
|
|
// Use of this source code is governed by the MIT license that can be
|
|
|
|
// found in the LICENSE file.
|
|
|
|
|
2019-06-19 20:46:59 +00:00
|
|
|
#include "shell/browser/native_browser_view_views.h"
|
Implement initial, experimental BrowserView API
Right now, `<webview>` is the only way to embed additional content in a
`BrowserWindow`. Unfortunately `<webview>` suffers from a [number of
problems](https://github.com/electron/electron/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20label%3Awebview%20).
To make matters worse, many of these are upstream Chromium bugs instead
of Electron-specific bugs.
For us at [Figma](https://www.figma.com), the main issue is very slow
performance.
Despite the upstream improvements to `<webview>` through the OOPIF work, it is
probable that there will continue to be `<webview>`-specific bugs in the
future.
Therefore, this introduces a `<webview>` alternative to called `BrowserView`,
which...
- is a thin wrapper around `api::WebContents` (so bugs in `BrowserView` will
likely also be bugs in `BrowserWindow` web contents)
- is instantiated in the main process like `BrowserWindow` (and unlike
`<webview>`, which lives in the DOM of a `BrowserWindow` web contents)
- needs to be added to a `BrowserWindow` to display something on the screen
This implements the most basic API. The API is expected to evolve and change in
the near future and has consequently been marked as experimental. Please do not
use this API in production unless you are prepared to deal with breaking
changes.
In the future, we will want to change the API to support multiple
`BrowserView`s per window. We will also want to consider z-ordering
auto-resizing, and possibly even nested views.
2017-04-11 17:47:30 +00:00
|
|
|
|
2020-12-01 23:03:00 +00:00
|
|
|
#include <vector>
|
|
|
|
|
|
|
|
#include "shell/browser/ui/drag_util.h"
|
2021-07-29 23:59:24 +00:00
|
|
|
#include "shell/browser/ui/views/inspectable_web_contents_view_views.h"
|
Implement initial, experimental BrowserView API
Right now, `<webview>` is the only way to embed additional content in a
`BrowserWindow`. Unfortunately `<webview>` suffers from a [number of
problems](https://github.com/electron/electron/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20label%3Awebview%20).
To make matters worse, many of these are upstream Chromium bugs instead
of Electron-specific bugs.
For us at [Figma](https://www.figma.com), the main issue is very slow
performance.
Despite the upstream improvements to `<webview>` through the OOPIF work, it is
probable that there will continue to be `<webview>`-specific bugs in the
future.
Therefore, this introduces a `<webview>` alternative to called `BrowserView`,
which...
- is a thin wrapper around `api::WebContents` (so bugs in `BrowserView` will
likely also be bugs in `BrowserWindow` web contents)
- is instantiated in the main process like `BrowserWindow` (and unlike
`<webview>`, which lives in the DOM of a `BrowserWindow` web contents)
- needs to be added to a `BrowserWindow` to display something on the screen
This implements the most basic API. The API is expected to evolve and change in
the near future and has consequently been marked as experimental. Please do not
use this API in production unless you are prepared to deal with breaking
changes.
In the future, we will want to change the API to support multiple
`BrowserView`s per window. We will also want to consider z-ordering
auto-resizing, and possibly even nested views.
2017-04-11 17:47:30 +00:00
|
|
|
#include "ui/gfx/geometry/rect.h"
|
|
|
|
#include "ui/views/background.h"
|
|
|
|
#include "ui/views/view.h"
|
|
|
|
|
|
|
|
namespace electron {
|
|
|
|
|
|
|
|
NativeBrowserViewViews::NativeBrowserViewViews(
|
2018-10-19 13:50:30 +00:00
|
|
|
InspectableWebContents* inspectable_web_contents)
|
2018-03-19 07:50:30 +00:00
|
|
|
: NativeBrowserView(inspectable_web_contents) {}
|
Implement initial, experimental BrowserView API
Right now, `<webview>` is the only way to embed additional content in a
`BrowserWindow`. Unfortunately `<webview>` suffers from a [number of
problems](https://github.com/electron/electron/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20label%3Awebview%20).
To make matters worse, many of these are upstream Chromium bugs instead
of Electron-specific bugs.
For us at [Figma](https://www.figma.com), the main issue is very slow
performance.
Despite the upstream improvements to `<webview>` through the OOPIF work, it is
probable that there will continue to be `<webview>`-specific bugs in the
future.
Therefore, this introduces a `<webview>` alternative to called `BrowserView`,
which...
- is a thin wrapper around `api::WebContents` (so bugs in `BrowserView` will
likely also be bugs in `BrowserWindow` web contents)
- is instantiated in the main process like `BrowserWindow` (and unlike
`<webview>`, which lives in the DOM of a `BrowserWindow` web contents)
- needs to be added to a `BrowserWindow` to display something on the screen
This implements the most basic API. The API is expected to evolve and change in
the near future and has consequently been marked as experimental. Please do not
use this API in production unless you are prepared to deal with breaking
changes.
In the future, we will want to change the API to support multiple
`BrowserView`s per window. We will also want to consider z-ordering
auto-resizing, and possibly even nested views.
2017-04-11 17:47:30 +00:00
|
|
|
|
2019-09-16 22:12:00 +00:00
|
|
|
NativeBrowserViewViews::~NativeBrowserViewViews() = default;
|
Implement initial, experimental BrowserView API
Right now, `<webview>` is the only way to embed additional content in a
`BrowserWindow`. Unfortunately `<webview>` suffers from a [number of
problems](https://github.com/electron/electron/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20label%3Awebview%20).
To make matters worse, many of these are upstream Chromium bugs instead
of Electron-specific bugs.
For us at [Figma](https://www.figma.com), the main issue is very slow
performance.
Despite the upstream improvements to `<webview>` through the OOPIF work, it is
probable that there will continue to be `<webview>`-specific bugs in the
future.
Therefore, this introduces a `<webview>` alternative to called `BrowserView`,
which...
- is a thin wrapper around `api::WebContents` (so bugs in `BrowserView` will
likely also be bugs in `BrowserWindow` web contents)
- is instantiated in the main process like `BrowserWindow` (and unlike
`<webview>`, which lives in the DOM of a `BrowserWindow` web contents)
- needs to be added to a `BrowserWindow` to display something on the screen
This implements the most basic API. The API is expected to evolve and change in
the near future and has consequently been marked as experimental. Please do not
use this API in production unless you are prepared to deal with breaking
changes.
In the future, we will want to change the API to support multiple
`BrowserView`s per window. We will also want to consider z-ordering
auto-resizing, and possibly even nested views.
2017-04-11 17:47:30 +00:00
|
|
|
|
2018-05-16 19:12:45 +00:00
|
|
|
void NativeBrowserViewViews::SetAutoResizeFlags(uint8_t flags) {
|
|
|
|
auto_resize_flags_ = flags;
|
2019-01-31 02:07:19 +00:00
|
|
|
ResetAutoResizeProportions();
|
|
|
|
}
|
|
|
|
|
2020-12-01 23:03:00 +00:00
|
|
|
void NativeBrowserViewViews::UpdateDraggableRegions(
|
|
|
|
const std::vector<mojom::DraggableRegionPtr>& regions) {
|
2022-06-17 10:01:38 +00:00
|
|
|
if (&draggable_regions_ != ®ions)
|
|
|
|
draggable_regions_ = mojo::Clone(regions);
|
|
|
|
|
2020-12-01 23:03:00 +00:00
|
|
|
// We need to snap the regions to the bounds of the current BrowserView.
|
|
|
|
// For example, if an attached BrowserView is draggable but its bounds are
|
|
|
|
// { x: 200, y: 100, width: 300, height: 300 }
|
|
|
|
// then we need to add 200 to the x-value and 100 to the
|
|
|
|
// y-value of each of the passed regions or it will be incorrectly
|
|
|
|
// assumed that the regions begin in the top left corner as they
|
|
|
|
// would for the main client window.
|
|
|
|
auto const offset = GetBounds().OffsetFromOrigin();
|
2022-06-17 10:01:38 +00:00
|
|
|
for (auto& snapped_region : draggable_regions_) {
|
2020-12-01 23:03:00 +00:00
|
|
|
snapped_region->bounds.Offset(offset);
|
|
|
|
}
|
2022-06-17 10:01:38 +00:00
|
|
|
draggable_region_ = DraggableRegionsToSkRegion(draggable_regions_);
|
2020-12-01 23:03:00 +00:00
|
|
|
}
|
|
|
|
|
2019-01-31 02:07:19 +00:00
|
|
|
void NativeBrowserViewViews::SetAutoResizeProportions(
|
|
|
|
const gfx::Size& window_size) {
|
|
|
|
if ((auto_resize_flags_ & AutoResizeFlags::kAutoResizeHorizontal) &&
|
|
|
|
!auto_horizontal_proportion_set_) {
|
2021-07-29 23:59:24 +00:00
|
|
|
InspectableWebContentsView* iwc_view = GetInspectableWebContentsView();
|
2020-10-19 16:26:38 +00:00
|
|
|
if (!iwc_view)
|
2020-09-17 00:10:49 +00:00
|
|
|
return;
|
|
|
|
auto* view = iwc_view->GetView();
|
2019-01-31 02:07:19 +00:00
|
|
|
auto view_bounds = view->bounds();
|
|
|
|
auto_horizontal_proportion_width_ =
|
|
|
|
static_cast<float>(window_size.width()) /
|
|
|
|
static_cast<float>(view_bounds.width());
|
|
|
|
auto_horizontal_proportion_left_ = static_cast<float>(window_size.width()) /
|
|
|
|
static_cast<float>(view_bounds.x());
|
|
|
|
auto_horizontal_proportion_set_ = true;
|
|
|
|
}
|
|
|
|
if ((auto_resize_flags_ & AutoResizeFlags::kAutoResizeVertical) &&
|
|
|
|
!auto_vertical_proportion_set_) {
|
2021-07-29 23:59:24 +00:00
|
|
|
InspectableWebContentsView* iwc_view = GetInspectableWebContentsView();
|
2020-10-19 16:26:38 +00:00
|
|
|
if (!iwc_view)
|
2020-09-17 00:10:49 +00:00
|
|
|
return;
|
|
|
|
auto* view = iwc_view->GetView();
|
2019-01-31 02:07:19 +00:00
|
|
|
auto view_bounds = view->bounds();
|
|
|
|
auto_vertical_proportion_height_ =
|
|
|
|
static_cast<float>(window_size.height()) /
|
|
|
|
static_cast<float>(view_bounds.height());
|
|
|
|
auto_vertical_proportion_top_ = static_cast<float>(window_size.height()) /
|
|
|
|
static_cast<float>(view_bounds.y());
|
|
|
|
auto_vertical_proportion_set_ = true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void NativeBrowserViewViews::AutoResize(const gfx::Rect& new_window,
|
|
|
|
int width_delta,
|
|
|
|
int height_delta) {
|
2021-07-29 23:59:24 +00:00
|
|
|
InspectableWebContentsView* iwc_view = GetInspectableWebContentsView();
|
2020-10-19 16:26:38 +00:00
|
|
|
if (!iwc_view)
|
2020-09-17 00:10:49 +00:00
|
|
|
return;
|
|
|
|
auto* view = iwc_view->GetView();
|
2019-01-31 02:07:19 +00:00
|
|
|
const auto flags = GetAutoResizeFlags();
|
|
|
|
if (!(flags & kAutoResizeWidth)) {
|
|
|
|
width_delta = 0;
|
|
|
|
}
|
|
|
|
if (!(flags & kAutoResizeHeight)) {
|
|
|
|
height_delta = 0;
|
|
|
|
}
|
|
|
|
if (height_delta || width_delta) {
|
|
|
|
auto new_view_size = view->size();
|
|
|
|
new_view_size.set_width(new_view_size.width() + width_delta);
|
|
|
|
new_view_size.set_height(new_view_size.height() + height_delta);
|
|
|
|
view->SetSize(new_view_size);
|
|
|
|
}
|
|
|
|
auto new_view_bounds = view->bounds();
|
|
|
|
if (flags & kAutoResizeHorizontal) {
|
|
|
|
new_view_bounds.set_width(new_window.width() /
|
|
|
|
auto_horizontal_proportion_width_);
|
|
|
|
new_view_bounds.set_x(new_window.width() /
|
|
|
|
auto_horizontal_proportion_left_);
|
|
|
|
}
|
|
|
|
if (flags & kAutoResizeVertical) {
|
|
|
|
new_view_bounds.set_height(new_window.height() /
|
|
|
|
auto_vertical_proportion_height_);
|
|
|
|
new_view_bounds.set_y(new_window.height() / auto_vertical_proportion_top_);
|
|
|
|
}
|
|
|
|
if ((flags & kAutoResizeHorizontal) || (flags & kAutoResizeVertical)) {
|
|
|
|
view->SetBoundsRect(new_view_bounds);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void NativeBrowserViewViews::ResetAutoResizeProportions() {
|
|
|
|
if (auto_resize_flags_ & AutoResizeFlags::kAutoResizeHorizontal) {
|
|
|
|
auto_horizontal_proportion_set_ = false;
|
|
|
|
}
|
|
|
|
if (auto_resize_flags_ & AutoResizeFlags::kAutoResizeVertical) {
|
|
|
|
auto_vertical_proportion_set_ = false;
|
|
|
|
}
|
2018-05-16 19:12:45 +00:00
|
|
|
}
|
|
|
|
|
Implement initial, experimental BrowserView API
Right now, `<webview>` is the only way to embed additional content in a
`BrowserWindow`. Unfortunately `<webview>` suffers from a [number of
problems](https://github.com/electron/electron/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20label%3Awebview%20).
To make matters worse, many of these are upstream Chromium bugs instead
of Electron-specific bugs.
For us at [Figma](https://www.figma.com), the main issue is very slow
performance.
Despite the upstream improvements to `<webview>` through the OOPIF work, it is
probable that there will continue to be `<webview>`-specific bugs in the
future.
Therefore, this introduces a `<webview>` alternative to called `BrowserView`,
which...
- is a thin wrapper around `api::WebContents` (so bugs in `BrowserView` will
likely also be bugs in `BrowserWindow` web contents)
- is instantiated in the main process like `BrowserWindow` (and unlike
`<webview>`, which lives in the DOM of a `BrowserWindow` web contents)
- needs to be added to a `BrowserWindow` to display something on the screen
This implements the most basic API. The API is expected to evolve and change in
the near future and has consequently been marked as experimental. Please do not
use this API in production unless you are prepared to deal with breaking
changes.
In the future, we will want to change the API to support multiple
`BrowserView`s per window. We will also want to consider z-ordering
auto-resizing, and possibly even nested views.
2017-04-11 17:47:30 +00:00
|
|
|
void NativeBrowserViewViews::SetBounds(const gfx::Rect& bounds) {
|
2021-07-29 23:59:24 +00:00
|
|
|
InspectableWebContentsView* iwc_view = GetInspectableWebContentsView();
|
2020-09-17 00:10:49 +00:00
|
|
|
if (!iwc_view)
|
|
|
|
return;
|
|
|
|
auto* view = iwc_view->GetView();
|
Implement initial, experimental BrowserView API
Right now, `<webview>` is the only way to embed additional content in a
`BrowserWindow`. Unfortunately `<webview>` suffers from a [number of
problems](https://github.com/electron/electron/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20label%3Awebview%20).
To make matters worse, many of these are upstream Chromium bugs instead
of Electron-specific bugs.
For us at [Figma](https://www.figma.com), the main issue is very slow
performance.
Despite the upstream improvements to `<webview>` through the OOPIF work, it is
probable that there will continue to be `<webview>`-specific bugs in the
future.
Therefore, this introduces a `<webview>` alternative to called `BrowserView`,
which...
- is a thin wrapper around `api::WebContents` (so bugs in `BrowserView` will
likely also be bugs in `BrowserWindow` web contents)
- is instantiated in the main process like `BrowserWindow` (and unlike
`<webview>`, which lives in the DOM of a `BrowserWindow` web contents)
- needs to be added to a `BrowserWindow` to display something on the screen
This implements the most basic API. The API is expected to evolve and change in
the near future and has consequently been marked as experimental. Please do not
use this API in production unless you are prepared to deal with breaking
changes.
In the future, we will want to change the API to support multiple
`BrowserView`s per window. We will also want to consider z-ordering
auto-resizing, and possibly even nested views.
2017-04-11 17:47:30 +00:00
|
|
|
view->SetBoundsRect(bounds);
|
2019-01-31 02:07:19 +00:00
|
|
|
ResetAutoResizeProportions();
|
2022-06-17 10:01:38 +00:00
|
|
|
|
2022-06-20 04:31:53 +00:00
|
|
|
view->InvalidateLayout();
|
|
|
|
view->SchedulePaint();
|
|
|
|
|
2022-06-17 10:01:38 +00:00
|
|
|
// Ensure draggable regions are properly updated to reflect new bounds.
|
|
|
|
UpdateDraggableRegions(draggable_regions_);
|
Implement initial, experimental BrowserView API
Right now, `<webview>` is the only way to embed additional content in a
`BrowserWindow`. Unfortunately `<webview>` suffers from a [number of
problems](https://github.com/electron/electron/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20label%3Awebview%20).
To make matters worse, many of these are upstream Chromium bugs instead
of Electron-specific bugs.
For us at [Figma](https://www.figma.com), the main issue is very slow
performance.
Despite the upstream improvements to `<webview>` through the OOPIF work, it is
probable that there will continue to be `<webview>`-specific bugs in the
future.
Therefore, this introduces a `<webview>` alternative to called `BrowserView`,
which...
- is a thin wrapper around `api::WebContents` (so bugs in `BrowserView` will
likely also be bugs in `BrowserWindow` web contents)
- is instantiated in the main process like `BrowserWindow` (and unlike
`<webview>`, which lives in the DOM of a `BrowserWindow` web contents)
- needs to be added to a `BrowserWindow` to display something on the screen
This implements the most basic API. The API is expected to evolve and change in
the near future and has consequently been marked as experimental. Please do not
use this API in production unless you are prepared to deal with breaking
changes.
In the future, we will want to change the API to support multiple
`BrowserView`s per window. We will also want to consider z-ordering
auto-resizing, and possibly even nested views.
2017-04-11 17:47:30 +00:00
|
|
|
}
|
|
|
|
|
2019-07-30 02:43:05 +00:00
|
|
|
gfx::Rect NativeBrowserViewViews::GetBounds() {
|
2021-07-29 23:59:24 +00:00
|
|
|
InspectableWebContentsView* iwc_view = GetInspectableWebContentsView();
|
2020-09-17 00:10:49 +00:00
|
|
|
if (!iwc_view)
|
|
|
|
return gfx::Rect();
|
|
|
|
return iwc_view->GetView()->bounds();
|
2019-07-30 02:43:05 +00:00
|
|
|
}
|
|
|
|
|
2021-07-29 23:59:24 +00:00
|
|
|
void NativeBrowserViewViews::RenderViewReady() {
|
|
|
|
InspectableWebContentsView* iwc_view = GetInspectableWebContentsView();
|
|
|
|
if (iwc_view)
|
|
|
|
iwc_view->GetView()->Layout();
|
|
|
|
}
|
|
|
|
|
Implement initial, experimental BrowserView API
Right now, `<webview>` is the only way to embed additional content in a
`BrowserWindow`. Unfortunately `<webview>` suffers from a [number of
problems](https://github.com/electron/electron/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20label%3Awebview%20).
To make matters worse, many of these are upstream Chromium bugs instead
of Electron-specific bugs.
For us at [Figma](https://www.figma.com), the main issue is very slow
performance.
Despite the upstream improvements to `<webview>` through the OOPIF work, it is
probable that there will continue to be `<webview>`-specific bugs in the
future.
Therefore, this introduces a `<webview>` alternative to called `BrowserView`,
which...
- is a thin wrapper around `api::WebContents` (so bugs in `BrowserView` will
likely also be bugs in `BrowserWindow` web contents)
- is instantiated in the main process like `BrowserWindow` (and unlike
`<webview>`, which lives in the DOM of a `BrowserWindow` web contents)
- needs to be added to a `BrowserWindow` to display something on the screen
This implements the most basic API. The API is expected to evolve and change in
the near future and has consequently been marked as experimental. Please do not
use this API in production unless you are prepared to deal with breaking
changes.
In the future, we will want to change the API to support multiple
`BrowserView`s per window. We will also want to consider z-ordering
auto-resizing, and possibly even nested views.
2017-04-11 17:47:30 +00:00
|
|
|
void NativeBrowserViewViews::SetBackgroundColor(SkColor color) {
|
2021-07-29 23:59:24 +00:00
|
|
|
InspectableWebContentsView* iwc_view = GetInspectableWebContentsView();
|
2020-09-17 00:10:49 +00:00
|
|
|
if (!iwc_view)
|
|
|
|
return;
|
|
|
|
auto* view = iwc_view->GetView();
|
2017-09-12 15:33:27 +00:00
|
|
|
view->SetBackground(views::CreateSolidBackground(color));
|
2018-11-21 19:04:10 +00:00
|
|
|
view->SchedulePaint();
|
Implement initial, experimental BrowserView API
Right now, `<webview>` is the only way to embed additional content in a
`BrowserWindow`. Unfortunately `<webview>` suffers from a [number of
problems](https://github.com/electron/electron/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20label%3Awebview%20).
To make matters worse, many of these are upstream Chromium bugs instead
of Electron-specific bugs.
For us at [Figma](https://www.figma.com), the main issue is very slow
performance.
Despite the upstream improvements to `<webview>` through the OOPIF work, it is
probable that there will continue to be `<webview>`-specific bugs in the
future.
Therefore, this introduces a `<webview>` alternative to called `BrowserView`,
which...
- is a thin wrapper around `api::WebContents` (so bugs in `BrowserView` will
likely also be bugs in `BrowserWindow` web contents)
- is instantiated in the main process like `BrowserWindow` (and unlike
`<webview>`, which lives in the DOM of a `BrowserWindow` web contents)
- needs to be added to a `BrowserWindow` to display something on the screen
This implements the most basic API. The API is expected to evolve and change in
the near future and has consequently been marked as experimental. Please do not
use this API in production unless you are prepared to deal with breaking
changes.
In the future, we will want to change the API to support multiple
`BrowserView`s per window. We will also want to consider z-ordering
auto-resizing, and possibly even nested views.
2017-04-11 17:47:30 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// static
|
|
|
|
NativeBrowserView* NativeBrowserView::Create(
|
2018-10-19 13:50:30 +00:00
|
|
|
InspectableWebContents* inspectable_web_contents) {
|
2018-03-19 07:50:30 +00:00
|
|
|
return new NativeBrowserViewViews(inspectable_web_contents);
|
Implement initial, experimental BrowserView API
Right now, `<webview>` is the only way to embed additional content in a
`BrowserWindow`. Unfortunately `<webview>` suffers from a [number of
problems](https://github.com/electron/electron/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20label%3Awebview%20).
To make matters worse, many of these are upstream Chromium bugs instead
of Electron-specific bugs.
For us at [Figma](https://www.figma.com), the main issue is very slow
performance.
Despite the upstream improvements to `<webview>` through the OOPIF work, it is
probable that there will continue to be `<webview>`-specific bugs in the
future.
Therefore, this introduces a `<webview>` alternative to called `BrowserView`,
which...
- is a thin wrapper around `api::WebContents` (so bugs in `BrowserView` will
likely also be bugs in `BrowserWindow` web contents)
- is instantiated in the main process like `BrowserWindow` (and unlike
`<webview>`, which lives in the DOM of a `BrowserWindow` web contents)
- needs to be added to a `BrowserWindow` to display something on the screen
This implements the most basic API. The API is expected to evolve and change in
the near future and has consequently been marked as experimental. Please do not
use this API in production unless you are prepared to deal with breaking
changes.
In the future, we will want to change the API to support multiple
`BrowserView`s per window. We will also want to consider z-ordering
auto-resizing, and possibly even nested views.
2017-04-11 17:47:30 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
} // namespace electron
|