[Updater] Close a running Cockatrice when the installer asks (#7672)

* [Updater] Refuse a close that arrives while one is already asking

MainWindow::closeEvent() had a re-entrancy guard that returned without touching
the event. A QCloseEvent is accepted unless something ignores it, so a second
close request - an installer replacing our files posts one every 30 s - accepted
the close while the first one was still blocked on its own confirmation. close()
then hid this window, hid the confirmation dialog with it, and left the process
running inside the nested loop that dialog had opened: no window, no way to
answer it, and every later close request accepted into the same dead end. That
is what an update looked like when it could not close a running client, and it
is why the installer could name the process, bring it forward and ask it to
close for minutes without anything happening.

Track how far the shutdown has got instead. While a confirmation is up, a close
from anywhere else is refused, which leaves the question in front of the user;
once the shutdown has been accepted, a duplicate close (Qt delivers the event
twice on some platforms) is accepted again so it cannot cancel the quit.

* [Installer] Leave an instance that is asking a question alone

An instance that answered a close by hiding rather than quitting - the state the
client used to get into - has no visible window left, and the confirmation it is
waiting on is hidden with the window that owns it. The close probe only ever
looked at visible windows, so it restored the main window, posted WM_CLOSE into
the same dead end, and reported "still running" without saying why.

Show every window the instance left hidden before choosing the one to close, and
skip the close when the window it would reach is disabled: a modal dialog of the
instance's own is up, and posting the close then only hides the question again.
Name what is left of the window in the report as well - gone, still open, hidden
again, and whether the thread answers at all - so the log tells a refused close
from one that was never delivered.

* [Installer] Offer to end a Cockatrice that will not close

A close is a request, and an instance that does not answer it - waiting on a
question nobody is looking at, or stuck where a close cannot reach - leaves the
user with no way forward: the files cannot be replaced while it runs, and
clicking Yes again only repeats the request.

After a second close that changed nothing, offer the only thing that can free
the files: end it. The prompt says what it costs - an unsaved deck, a running
game or a setting it has not written yet - the default button is the safe one,
and it is a separate answer rather than a relabelled "Yes", so it is not
reached by clicking through the close prompt. Only cockatrice.exe is ever
ended: Oracle writes the card database in place and Servatrice is a service, so
both are named and left to the user, exactly as they are for the close.

The probe gains an --end-holders mode for it, and the uninstaller's guard gets
the same offer.

* [Installer] Never name the process that is doing the asking

The old uninstaller is started with _?= so it runs in place, from the very
directory it is emptying, and an installer can be downloaded into the folder it
installs to. Both are then processes running from the directory, so the probe
named them - and the guard asked the user to close the program that was asking.
That question cannot be answered: a close and the end offer both skip anything
that is not cockatrice.exe, so the guard repeated itself until the update or the
uninstall was cancelled.

The probe and the processes that started it are now never named, by either
lookup. The walk up the parent chain stops at the first program the payload
installs, because in an in-app update the installer's own parent is the
Cockatrice instance being replaced - the one the guard exists to name.

The Windows check held its locked file in the script that starts the probe, so
that holder is excluded by design now and the check read it as "nothing found".
It holds the file from a process of its own instead, and asserts the exclusion
itself: a file that only the asking process holds comes back as nothing.

* [Installer] Restore only the windows a user could answer

Showing every hidden window an instance owns put Qt's own bookkeeping windows on
screen: the tray icon keeps one to receive the TaskbarCreated message, styled
WS_OVERLAPPED and titled QTrayIconMessageWindow. Restored, it is an empty white
rectangle in the taskbar with no title bar to close it - it has no window
procedure that would hide it again, and the process is busy in the very loop the
restore is meant to break, so it stayed until the process was force-ended.

Only framed, non-empty windows are restored and considered for the close now.
That also keeps the close off Qt's tray window, which answers WM_CLOSE by asking
the application to terminate - a quit that skips the confirmation the close is
supposed to reach.

* [Installer] Uninstall the previous version before installing over it

A regular install over an existing one asked "a previous version must be
uninstalled", then ran the old uninstaller interactively. That uninstaller
put its confirmation page behind the installer window, where it could not be
answered, and it only removed the installation after the installer had
already written the new one over it.

Run the previous version's uninstaller silently instead. The installer has
already asked the question the user answered, so a second, hidden confirmation
is pure risk: with /S there is no window to be behind, and ExecWait is then
waiting for something that cannot outlive it. QuietUninstallString is used
when the old installation has one, otherwise /S is appended.

ExecWait only waits while the uninstaller runs in place: one that did not get
a usable _?= copies itself to %TEMP% and returns at once, while the copy keeps
deleting - which is how an uninstall can finish after the install it was
supposed to precede. Log the exit code and wait for the old cockatrice.exe to
disappear before restoring user data or writing anything, and abort with a
message instead of installing into a directory that is still being emptied.

Cancelling the "must be uninstalled" prompt now quits the installer; it used
to skip the page and install over the old version anyway.

* [Installer] Do not show windows the application has hidden

The guard restored every hidden window an instance owned before asking it to
close, so that a confirmation hidden together with its window would come back.
Windows does as it is told and shows them; the application does not, because Qt
still believes they are hidden and never paints them. What the user gets is a
blank white rectangle, on screen and on the taskbar, that answers nothing - and
the question it was meant to bring back is not answerable in it either.

An instance with no window a user could answer is named and left to the user
instead, and the prompt says what to do about it: open it from the notification
area. Ending it stays the last resort, offered once a close has been asked for
twice.

The abort after a failed uninstall now says what it saw - the old version is
still there after its uninstaller ran - instead of promising a removal that is
not happening, which is the state a cancelled old uninstaller leaves behind.

---------

Co-authored-by: Lukas Brübach <Bruebach.Lukas@bdosecurity.de>

cockatrice/src/interface/window_main.cpp

@@ -923,11 +923,28 @@ void MainWindow::actShow()
 
 void MainWindow::closeEvent(QCloseEvent *event)
 {
-    // workaround Qt bug where closeEvent gets called twice
-    if (bClosingDown) {
-        return;
+    switch (shutdownState) {
+        case ShutdownState::Accepted:
+            // A duplicate close for a shutdown that already went through (Qt delivers the event
+            // twice on some platforms). Accepting it again keeps the quit that is already under
+            // way; ignoring it would cancel it.
+            event->accept();
+            return;
+        case ShutdownState::Confirming:
+            // A second close request arrived while one of our own confirmations is up. Another
+            // program asking us to close - an installer replacing our files, for one - looks
+            // exactly like this, and accepting it would be destructive: close() hides this
+            // window, hides the dialog with it, and leaves the process running inside the nested
+            // loop that dialog opened. Nothing can reach that loop afterwards, so the process
+            // stays alive with no window and every later close request is accepted into the same
+            // dead end. Refuse this one and leave the question in front of the user; the shutdown
+            // that is already running finishes as soon as they answer it.
+            event->ignore();
+            return;
+        case ShutdownState::Idle:
+            break;
     }
-    bClosingDown = true;
+    shutdownState = ShutdownState::Confirming;
 
     if (cardUpdateProcess && cardUpdateProcess->state() != QProcess::NotRunning) {
         const QString runningFor = cardUpdateStatusBar ? cardUpdateStatusBar->statusText() : QString();
@@ -939,19 +956,20 @@ void MainWindow::closeEvent(QCloseEvent *event)
                                           .arg(runningFor);
         if (!QtUtils::confirm(this, tr("Are you sure?"), message, QMessageBox::No)) {
             event->ignore();
-            bClosingDown = false;
+            shutdownState = ShutdownState::Idle;
             return;
         }
     }
 
     if (!tabSupervisor->close()) {
         event->ignore();
-        bClosingDown = false;
+        shutdownState = ShutdownState::Idle;
         return;
     }
     tip->close();
 
     event->accept();
+    shutdownState = ShutdownState::Accepted;
     SettingsCache::instance().layouts().setMainWindowGeometry(saveGeometry());
     tabSupervisor->deleteLater();
 }
@@ -962,7 +980,7 @@ bool MainWindow::closeForUpdate()
     // closeEvent() is blocked on a user prompt). close() would hit the re-entrancy guard and return
     // true without any shutdown having happened, so report faithfully instead: the caller must keep
     // the process alive until the user resolves whatever is blocking the close.
-    if (bClosingDown) {
+    if (shutdownState != ShutdownState::Idle) {
         return false;
     }
     return close();

cockatrice/src/interface/window_main.h

@@ -194,7 +194,17 @@ private:
     LagMonitor lagMonitor;                        ///< watches the main thread for event loop stalls
     LatencyStatusWidget *latencyStatus = nullptr; ///< status bar widget with live round-trip stats and history graph
     bool bHasActivated, askedForDbUpdater;
-    bool bClosingDown = false; ///< guards closeEvent() against re-entrancy
+    /**
+     * How far a shutdown that was asked for has got. A close request that arrives while one is
+     * already asking the user something must not be accepted - see closeEvent().
+     */
+    enum class ShutdownState
+    {
+        Idle,       ///< no shutdown has been asked for
+        Confirming, ///< asking about a card database update, open games or an unsaved deck
+        Accepted,   ///< the close was accepted and the window is hiding
+    };
+    ShutdownState shutdownState = ShutdownState::Idle;
     bool skipStartupAutoConnect = false;
     bool startupAutoConnectAttempted = false;
     bool firstRunWizardActive = false;