During a startup update check that ends in a skip (no install), the update splash is destroyed as soon as the normal UI is opened. When the boot is a startup-restore boot (autoLaunchOnStartup set to an instance), the chooser host window is created hidden and only revealed once the instance launch takeover is ready (or the 10s reveal backstop fires). This leaves a few seconds where no window is visible: the splash is gone and the restore window has not revealed yet.
This is cosmetic only. A live window exists, so window-all-closed never fires and the app stays alive. The blank interval is also identical to what a normal restore boot (without a pending update) already shows by design, since the window is deliberately kept hidden until its takeover is up so the dashboard never flashes.
Proposed improvement (deferred from PR #1473 review):
- Change the splash-destroy condition from "another live window exists" to "another visible window exists".
- If the only other window is alive but hidden, attach a one-shot show listener on it and destroy the splash at reveal, plus a backstop timer (~15s, past the 10s reveal backstop) that destroys the splash regardless.
- Every splash-destroy point must re-evaluate the last-window guard at fire time: destroying the splash while it is the last window fires window-all-closed and quits the app, which is the original update-loop bug. In particular, if the hidden window is destroyed before ever showing, the backstop must keep the splash up rather than quit.
- Add a third splash copy state (e.g. "Starting Comfy Desktop...") swapped in once the update check resolves as skip, so the splash does not keep saying "A downloaded update is being verified" while the app is actually launching the restored instance. The render-chaining pattern in updateSplash.ts already supports this.
Raised by CodeRabbit review on PR #1473; deferred there because the fix is complete without it and the extra splash lifecycle complexity was not worth blocking the loop fix.
During a startup update check that ends in a skip (no install), the update splash is destroyed as soon as the normal UI is opened. When the boot is a startup-restore boot (autoLaunchOnStartup set to an instance), the chooser host window is created hidden and only revealed once the instance launch takeover is ready (or the 10s reveal backstop fires). This leaves a few seconds where no window is visible: the splash is gone and the restore window has not revealed yet.
This is cosmetic only. A live window exists, so window-all-closed never fires and the app stays alive. The blank interval is also identical to what a normal restore boot (without a pending update) already shows by design, since the window is deliberately kept hidden until its takeover is up so the dashboard never flashes.
Proposed improvement (deferred from PR #1473 review):
Raised by CodeRabbit review on PR #1473; deferred there because the fix is complete without it and the extra splash lifecycle complexity was not worth blocking the loop fix.