Move AtomCTDelegate to brightray as RequireCTDelegate and transfer ownership to
brightray::URLRequestContextGetter. This fixes the wrong lifetime assumptions
that result in AtomCTDelegate being used after free in some scenarios.
Close#10051
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.
Add a gyp target that creates a browserify bundle starting with
`lib/sandboxed_renderer/init.js`, which is embedded into the executable using
the `atom_js2c` target.
The goal of this bundle is to provide a very basic environment for preload
scripts where a `require` function is available.
Add `app.getJumpListSettings()` and `app.setJumpList(callback)` that
make it possible to fully customize the Jump List of an Electron app.
It is now possible to:
- Add tasks to the standard `Tasks` category.
- Add separators to the standard `Tasks` category.
- Add custom categories containing tasks and file links.
- Add system managed Recent/Frequent categories.
- Remove the custom Jump List.
