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.
* Make the AtomNSWindow also a NSTouchbarDelegate
* Implement basic makeTouchBar and makeItemForIdentifier methods
* Initial sending of touch / update events through IPC to BrowserWindowObjects
TODO:
* JS API
* JS Object Converters
* Generalize methods so that popovers can work
The `disableAutoHideCursor` BrowserWindow option can be used to control
auto-hiding behavior when the window is created. This new API is needed
to dynamically change the behavior after the fact.
Adds a new "setSheetOffset" API to the `dialog` module, which allows you to change the attachment point for sheets on Mac OS X. I put the API on the dialog module, even though Mac OS X requires that the native window hold and return the desired offset.
1. I was originally hoping to make this an argument on the actual dialog.show* calls, but it seems the parameter set is defined in `libchromiumcontent` and I wasn't sure it would be appropriate to add there?
2. The API could also be on the BrowserWindow (eg `BrowserWindow.setSheetOffset`). I don't have a strong preference, but I think it's more discoverable on the `dialog` module.
In N1, we want to implement the famous "swipe to archive" action on threads in the user's inbox. Chrome exposes `scroll` and `wheel` events, but these aren't sufficient to implement the interaction because the element needs to "snap" when the user lifts their fingers from the trackpad, not when they / we stop receiving `wheel` / `scroll` events. These events may stop before the user lifts their fingers, or continue after the user has lifted their fingers if they had enough momentum for the gesture to continue.
This exposes BrowserWindow `scroll-touch-down` and `scroll-touch-up`, which fire immeditaely when the user touches two fingers to the trackpad, and again when the user lifts their fingers. Combined with the existing wheel event should allow for "swipe-to-archive" and other similar interactions.
Note: This is only implemented on Mac OS X and the events don't fire unless you're using a trackpad!
Related: #1486, #2683, https://github.com/nylas/N1/issues/541
Previously we implemented draggable region by tracking mouse position,
it is buggy and causing some problems. But it is interesting that until
this didn't cause troubles until recently.
