Commit graph

15 commits

Author SHA1 Message Date
Cheng Zhao
63874da087 test: add test for window.open in BrowserView 2018-11-27 11:10:07 +09:00
Cheng Zhao
746beb0d8b fix: destroy WebContents synchronously on shutdown (#15541) 2018-11-08 07:57:28 -08:00
Milan Burda
3ad3ade828 refactor: add prefer-const to .eslintrc + fix errors (#14880) 2018-10-02 11:56:31 +10:00
Samuel Attard
558fff69e7
chore: update to standard 12 2018-09-14 14:57:01 +10:00
Shelley Vohr
4dec5ec5f9
spec: update browser-view spec to expect (#13238)
* spec: update browser-view spec to expect
2018-06-17 15:56:04 -07:00
Birunthan Mohanathas
2681e769a6 Document BrowserView.{destroy,isDestroyed} (#12274) 2018-03-15 16:15:56 +09:00
Felix Rieseberg
690e8cf75b 👷 Add specs 2017-11-22 17:06:14 -08:00
Felix Rieseberg
541b369175 👷 Add a spec 2017-10-27 11:44:41 -07:00
Shelley Vohr
68314dbc05
remove stray only 2017-10-26 20:11:12 -04:00
Shelley Vohr
b53e41af42
migrate api-browser-view-spec to ES6 2017-10-26 20:05:15 -04:00
Siyuan Liu
ae7c1ae741 #10039 add BrowserView.fromId 2017-07-24 11:32:30 +08:00
Birunthan Mohanathas
eb19562316 Fix crash when using file chooser in BrowserView
The crash was a segfault caused by a null `WebDialogHelper::window_`.
2017-06-21 16:26:38 -07:00
Birunthan Mohanathas
ccdeb4746e Destroy BrowserViews after each test 2017-04-13 01:27:31 +03:00
Birunthan Mohanathas
06fcf2c19d Add support for BrowserView autoresizing 2017-04-13 01:27:31 +03:00
Birunthan Mohanathas
8b9f7e5b00 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-13 01:27:27 +03:00