Since spec windows don't register handlers for the IPC messages requested window state to be saved, the promise never resolves and the close button needs to be clicked twice. To avoid this, we'll just resolve the promise immediately in a spec window so we can proceed to close it.
This regression was caused by a nuance in the way we maintain state in
`AtomApplication` for open windows. Specifically, when closing the last
window on Windows and Linux, we were explicitly calling `app.quit`
*before* removing such window from the list of open ones. In turn, this
caused the new `before-quit` behavior introduced in #12619 to work
improperly because it made the application wait on saving the state of a
stale window before exiting.
With this commit we are fixing that by making sure the stale window is
removed before calling `app.quit` in `removeWindow`.
Previously, we used to save the window's state in the renderer process
`beforeunload` event handler: because of the synchronous nature of event
handlers and the asynchronous design of IndexedDB, this could
potentially not save anything if windows close fast enough to prevent
IndexedDB from committing the pending transaction containing the state.
(Ref.: https://mzl.la/2bXCXDn)
With this commit, we will intercept the `before-quit` events on
`electron.app` and the `close` event on `BrowserWindow` (which will fire
respectively before quitting the application and before closing a
window), and prevent them from performing the default action. We will
then ask each renderer process to save its state and, finally, close the
window and/or the app.
The flight manual page does not have a secure connection, so navigating
to the https link would result in a SSL_ERROR_BAD_CERT_DOMAIN error.
It might be better to add a secure connection to the server rather than
pulling this commit.
This, along with using a temporary directory as the ATOM_HOME, will make
sure that tests won't share any state with one another, possibly
increasing the level of resiliency of the suite.
This is needed in order to test configuration settings like
`restorePreviousWindowsOnStart`. Even if this call has side effects, its
scope is pretty constrained because it affects only the temporary
directory we create before each atom-application test.
...so that we can exercise loading previously opened windows stored
state after the application is restarted. In addition, this resembles
more what we run in production, and therefore allows us to have a better
coverage of the code paths we run in the real application.
