On Windows release builds, the found-in-page event test causes the test suite to hang. If the test is run individually, it works fine, but running it as part of the whole test suite causes the test suite to hang. This works around the issue in #13704 by temporarily disabling that test.
* Use Chai for webview tests
* Slightly rewrite one of the <webview> tests
"dom-ready event" > "throws a custom error..."
* Use Chai for BrowserWindow tests
* Rewrite BrowserWindow.addDevToolsExtension tests
* enable plznavigate code path
* AtomBrowserClient::GetGeolocationApiKey returns the right default
* use IsLoadingToDifferentDocument to identify top level navigation in mainFrame
* use candidate site instance when available
* spec: don't test httpReferrer option for file origin
* update libcc ref
* affinity: only group same site in this mode
* plznavigate: don't emit did-get-response-details event for blob scheme
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`).
