fix: show dock icon while Settings is open so update dialogs can front - #2818
Conversation
|
🦞👀 Pull request received. I will update this pull request when review starts. |
|
ClawSweeper status: review started. I am starting a fresh review of this pull request: fix: show dock icon while Settings is open so update dialogs can front This is item 1/1 in the current shard. Shard 0/1. This placeholder means the worker is alive and reading the current context. I will edit this same comment with the actual review when the claws are done clicking. Crustacean status: shell secured, claws on keyboard, evidence pebbles being sorted. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: bf0a26e5ee
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| self.ensureRegularPolicy(activate: hasNewPresentedWindow) | ||
| } | ||
|
|
||
| guard self.isManagingRegularPolicy, !self.isAwaitingPresentedWindow else { return } |
There was a problem hiding this comment.
If promote() is called but no Settings/Sparkle window is ultimately presented — for example the settings opener falls through both paths or Sparkle suppresses/fails the check before creating UI — isAwaitingPresentedWindow stays true forever. This guard then blocks every later reevaluation from returning the LSUIElement app to .accessory after all real windows are gone, so CodexBar can remain in the Dock until relaunch; reset the pending state on failed presentation or add a bounded timeout/no-window demotion path.
Useful? React with 👍 / 👎.
|
Live-tested on macOS 26 with the signed release-packaged bundle from this branch:
|
1 participant
Problem
CodexBar is packaged as an LSUIElement accessory app. Opening Settings did not change the activation policy, so Sparkle's Check for Updates and automatic new-version windows could appear behind other apps or fail to become key.
Root cause
The app remained on the accessory activation policy while presenting real windows. Calling activate alone is insufficient for reliable Dock presence and frontmost window behavior, and reverting too early can pull an update dialog away when Settings closes first.
Behavior
Test evidence
swift test --filter '(DockIconPolicyDecisionTests|SettingsWindowOpeningTests)'— 6 tests passed.make check— formatting, SwiftLint, manifests, package checks, docs, and repository gates passed.CODEXBAR_TEST_SUITE_TIMEOUT=600 make testthrough the structured review helper — all 833 selections in 70 groups passed; no retries or timeouts.Live source-blind UI validation was not run because app startup can exercise real Keychain migration/read paths, which repository safety rules prohibit without an explicit live-test request.