Commit graph

8 commits

Author SHA1 Message Date
shelley vohr
0e5b6f9300 Upgrade to node v9.3.0 (#11507)
* update submodule refs for node v9.3.0

* Define "llvm_version" for Node.js build

* NODE_MODULE_CONTEXT_AWARE_BUILTIN -> NODE_BUILTIN_MODULE_CONTEXT_AWARE

* update NodePlatform to MultiIsolatePlatform

* fix linting error

* update node ref

* REVIEW: Explicitly register builtin modules

https://github.com/nodejs/node/pull/16565

* update libcc ref

* switch libcc to c62

* REVIEW: Address node api changes

- Always start the inspector agent for https://github.com/nodejs/node/pull/17085
- Set the tracing controller for node https://github.com/nodejs/node/pull/15538
- Isolate data creation now requires plaform https://github.com/nodejs/node/pull/16700
2018-02-23 10:22:00 +09:00
Cheng Zhao
f8adaed763
Merge pull request #11208 from electron/mips64el
Add support for mips64el
2017-11-24 10:54:19 +09:00
Felix Rieseberg
3cb062b3d6 🔧 BrowserView.getAllViews() 2017-11-22 16:58:32 -08:00
Cheng Zhao
4f9c5310a9 Fix compiler warning when building with gcc 2017-11-21 21:47:51 +09:00
Siyuan Liu
ae7c1ae741 #10039 add BrowserView.fromId 2017-07-24 11:32:30 +08:00
deepak1556
0476e2fd3d destroy browserView webContents asynchronously 2017-05-01 16:53:55 +09: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