* feat: add multi BrowserView support to BrowserWindow
Add functions addBrowserView, removeBroserView, getBrowserViews to
BrowserWindow class. Existing API as setBrowserView and
getBrowserView code replaced to use new api inside.
* fix: for lint and osx compile errors
* fix: lint error in test code
* feat: add multi BrowserView support to BrowserWindow
Add functions addBrowserView, removeBroserView, getBrowserViews to
BrowserWindow class. Existing API as setBrowserView and
getBrowserView code replaced to use new api inside.
* fix: for lint and osx compile errors
* fix: lint error in test code
* fix: method to be accessible on mac api impl
* fix: missed function declarations for mac impl
* fix: use base class reset function
* Added mouse forward/back button support on Linux
* Added browser history navigation action bindings for Windows, Mac, and Linux keyboard
* Removed new `history-action` event and modified `app-command` to execute on such events
* Removed attempt at macOS support and added constants
* Clarified app-command documentation
* Reverted 'app-command' description change
* Format code
* chore: fix cpplint 'include_what_you_use' warnings
Typically by including <memory>, <utility> etc.
* chore: fix 'static/global string constant' warning
Use C style strings instead of std::string.
Style guide forbids non-trivial static / global variables. https://google.github.io/styleguide/cppguide.html#Static_and_Global_Variables
/home/charles/electron/electron-gn/src/electron/script/cpplint.js
* refactor: remove global string variables.
Fix 'global string variables are not permitted' linter warnings
by using the base::NoDestructor<> wrapper to make it explicit that
these variables are never destroyed.
The style guide's take on globals with nontrivial destructors:
https://google.github.io/styleguide/cppguide.html#Static_and_Global_Variables
* fix: initializer error introduced in last commit
* fix: remove WIP file that was included by accident
* fix: include order
* fix: include order
* fix: include order
* fix: include order, again
* First commit
* Add Mac support (1st attempt)
* Add Mac support (2nd attempt)
* Simplify tests
* Restore window state !
* Looking at other tests, seems minimize, maximize, fullscreen are skipped when in CI
* Fix Mac tests
* Restore tests in CI
* Fix typo
* widget getRestoredBounds not working on Mac !!
* widget getRestoredBounds not working on Mac !!
* Add IsNormal function
* Add IsNormal
* IsNormal => isNormal
* Deactivate fullscreen on Mac. Do not receive leave-fullscreen event
* Set default original_frame_
* Set default original_frame_
* Fix Mac
As opposed to the existing setIgnoreMouseEvents this call makes Chromium aware of mouse movements, allowing the user to stop forwarding according to movements in the webpage.
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.
