Repository navigation
2.11.1: windows from the menu bar come to the front (macOS 14+) - #26
Merged
Merged
Conversation
On macOS 14+ NSApp.activate() is a cooperative request. From a menu-bar (.accessory) app the front app often refuses it, so windows opened from the menu bar could open behind the front app. User-initiated paths now use activate(ignoringOtherApps:): About, Welcome and Settings. Not started by a click, so still cooperative: Sparkle update alerts; the history popup stays non-activating. Same fix as PullPing 0.7.0. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Sparkle: a "Check for Updates..." click (state.userInitiated) now activates forcefully; scheduled update reminders stay cooperative. No keepFront here: MaccyPlus windows (About, Welcome, Settings) never switch the activation policy, which is what triggers the hand-back. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A user-initiated update check also switches .accessory -> .regular before Sparkle shows its window, so macOS can hand activation back ~0.5 s later (release review). That branch now runs the same one-time keepFront guard, with no window of ours (nil). keepFront documents its known limit: a keyboard app switch within the 1.5 s is pulled back once. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Release review: on the update-window path (no window of ours), answering the update alert inside the 1.5 s switches back to .accessory, the app resigns active, and the guard would re-activate it with no window. The guard now also requires the .regular policy (window closed or update session over: stay out). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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.
Fixed
How
NSApp.activate()is a cooperative request on macOS 14+, and the front app often refuses it for an.accessoryapp. User-initiated paths now useactivate(ignoringOtherApps: true).keepFront: after the.accessory→.regularswitch, macOS hands activation back about 0.5 s later. The guard takes it back once within 1.5 s unless the user clicked elsewhere.state.userInitiated) is forceful and guarded. Scheduled reminders stay cooperative.Same fix as PullPing 0.7.0. Release review: APPROVE.
🤖 Generated with Claude Code