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.
- Use `path` module from browser process in sandboxed renderer. This is required
because the return value of `path.join` is platform-specific, and this is an
assumtion of crash-reporter.js which is shared between sandboxed and
non-sandboxed renderers.
- Set `process.platform` and `process.execPath` in sandboxed renderer
environment. This is required to spawn the windows crash service from
sandboxed renderer.
- Use a single temporary directory for all crashReporter tests. This is required
to make tests more deterministic across platforms(since mac's crashpad doesn't
support changing the crash dump directory). Also make a few improvements/fixes
to the `uploadToServer` test.
- Expose remote shortcuts for the `fs`, `os` and `child_process` modules.
- Expose the `url` and `timers` modules(the browserify versions)
- Add `process.crash` and `process.platform`
In sandboxed renderers we use browserify to provide a node-like environment. The
Buffer class used by browserify is actually just a wrapper around Uint8Array,
but to deserialize Buffer correctly we must expose the class as a hidden value
and use it in V8ValueConverter.
Instead of having to list in filenames.gypi every javascript file that may go
into a browserify build, generate this list dynamically when the build files are
created by gyp.
This change gives sandboxed renderer scripts a similar structure to what already
exists in the lib/{browser,renderer,common} directories.
It also allows sandboxed renderer initialization to share more code with
non-sandboxed renderers (ipcRenderer is now imported directly from
lib/renderer/api/ipc-renderer).
- Adapt node.cc code that implements `process.binding` to create a similar
object in AtomSandboxedRendererClient.
- Replace the ipc binding object passed to `lib/sandboxed_renderer/init.js` by
the new binding object.
- Refactor the initialization script to use this new object to fetch the ipc
binding and store as a hidden value using the `v8_util` module.
This change also required applying a patch to node.js, so the submodule commit
was updated.
