These new functions are more flexible than the other
{intercept,register}*ProtocoProtocol functions, since it allows the user to
return a node.js stream to feed the data to the protocol handler.
It also allows the user to specify a response header dictionary, which makes it
possible to correctly intercept any request made from renderers.
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.
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.
