Chromium already includes the necessary plumbing to manage the
visibility properties and `visibilitychange` event so this gets rid of
most of our custom logic for `BrowserWindow` and `BrowserView`.
Note that `webview` remains unchanged and is still affected by the issues
listed below.
User facing changes:
- The `document` visibility properties and `visibilitychange` event are
now also updated/fired in response to occlusion changes on macOS. In
other words, `document.visibilityState` will now be `hidden` on macOS
if the window is occluded by another window.
- Previously, `visibilitychange` was also fired by *both* Electron and
Chromium in some cases (e.g. when hiding the window). Now it is only
fired by Chromium so you no longer get duplicate events.
- The visiblity state of `BrowserWindow`s created with `{ show: false }`
is now initially `visible` until the window is shown and hidden.
- The visibility state of `BrowserWindow`s with `backgroundThrottling`
disabled is now permanently `visible`.
This should also fix#6860 (but not for `webview`).
When "sandboxed" is passed as a web preference for `BrowserWindow`, the newly
created renderer won't run any node.js code/integration, only communicating with
the system via the IPC API of the content module. This is a requirement for
running the renderer under chrome OS-level sandbox.
Beyond that, certain behaviors of AtomBrowserClient are modified when dealing
with sandboxed renderers:
- `OverrideSiteInstanceNavigation` no longer create a new `SiteInstance` for
every navigation. Instead, it reuses the source `SiteInstance` when not
navigating to a different site.
- `CanCreateWindow` will return true and allow javascript access.
