Repository navigation
fix(wallpaper): keep recovery state when Lively omits a running player - #296
Merged
Merged
Conversation
Lucas1479
marked this pull request as ready for review
November 6, 2026 11:42
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Refs #233. Keep the issue open: this fixes the Amadeus managed WebView2 recovery path; it does not change Lively's RPCs or certify its entire wallpaper registry.
What changed
Lively can acknowledge a project close while the player is still running. The #233 offline counterexample on main (
53f8f4f2) returned an empty inventory, discarded the recovery journal, and requested shutdown of the owned host while the simulated scene was still present.The Windows helper compares the number of live Amadeus WebView2 players with the number of entries Lively reports for the managed project. If there are more players than entries, cleanup is refused. A span player can keep its original launch display after Lively moves its entry to a new primary monitor, so the helper does not match launch display numbers. Restoration still checks the target monitor; a player can veto cleanup but cannot authorize killing a process or replacing a wallpaper.
This PR adds a two-second window after a project-scoped Close. If a player is still unaccounted for or inspection returns access denied, the helper rechecks both the Lively list and Windows processes within that window. Windows maps command-line query errors from NTSTATUS so that a terminating process receives the same access-denied handling as an image query. Denial alone never proves exit. A persistent discrepancy or inspection failure retains the journal and reports the failure. No dependency, setting, or journal migration.
Stock Lively 2.2.1.0 desktop evidence (earlier commit)
Product commit:
5658a379450978148c53ce6eb732053d555b6fc5. Disposable GitHub-hosted Windows Server 2025 VMs (build 26100, Explorer, one virtual display). The official installer matched SHA-25698f4e96bb8e2c416384eeaf48016eadaea9dce8263b8d212052775ebcf2d7e34; each job recorded hashes for the installed EXE, core DLL and WebView2 wrapper. No DLL or production helper was patched in the final runs. The test supervisor drove the real Electron application and checked native player state, the recovery journal and host ownership independently of the UI.recoverentry point returned restored, with zero managed players, no owned host, and the original Windows wallpaper.Nine desktop cases passed on
5658a379; they were not rerun on6ca878ef. The full spontaneous combination “settled false-empty inventory + no-op Close” was not observed. An empty list while Set is still Pending is not that failure; the induced Close failure above had a nonempty registry. The complete combined case remains covered by the offline counterexample and native process tests. No physical multi-monitor or general third-party-plugin qualification is claimed.Regression coverage on
6ca878efOn a clean export with Python 3.12.10 and pytest 8.4.2, 109 helper tests passed. Running the same tests with the earlier
5658a379helper failed the span/primary-display switch case and both NTSTATUS cases; the two refusal controls still passed. Ruff 0.16.3 passed on all three changed Python files. The span case uses a simulated Lively registry; physical multi-monitor behavior has not been validated. Current Electron Windows CI (includes parent lifecycle tests).Earlier failures and CI on
5658a3795658a379handled that image-query race without relaxing persistent access failures.5658a379: 105 Python helper tests and 706 Electron tests passed, including attached, crash and normal parent lifetime. Unpacked build and packaged wallpaper smoke passed.scheduledInstallassertion while installing a theme. That failure is separate from the nine stock-wallpaper results. On the targeted rerun at the identical commit, the same source-mode smoke passed without a plugin or test change. The cause of the first failure is unconfirmed. The rerun also passed the packaged app and catalog recovery roundtrip; all 16 GitHub checks passed on5658a379.