Fix intermittent failure to bring Preferences window forward - #47
Fix intermittent failure to bring Preferences window forward#47marcpbailey wants to merge 1 commit into
Conversation
Confirmed via NSLog instrumentation across repeated repro attempts: NSApp.activate() (macOS 14+) can silently decline to activate the app, with no error and no signal that it happened — the window then gets ordered front but stays behind whatever app was already frontmost. Switched to the forceful ignoringOtherApps: true unconditionally. It's deprecated in favor of activate(), but doesn't exhibit the same failure, and is the right tool here since this is a direct, deliberate user click on our own menu item rather than unsolicited background focus-stealing (the case the newer API's heuristics are meant to guard against). Accessory-policy (no Dock icon, i.e. LSUIElement) apps like this one are the sharpest edge case for window activation in general — see https://steipete.me/posts/2025/showing-settings-from-macos-menu-bar-items for a deeper workaround (temporarily switching to .regular activation policy) if this ever recurs.
|
I've never seeing this issue, and don't love always using a deprecated API. When have you seen this reproduce? |
|
Hi - thanks for looking at this so quickly. I LOVE your app btw, and have been extending it to Markdown editors as well - similar problem. Sometimes I need Obsidian, others MacDown, others Antigravity, etc. |
2 participants
Confirmed via repeated testing: NSApp.activate() (macOS 14+) can silently decline to activate the app, with no error and no signal that it happened — the window then gets ordered front but stays behind whatever app was already frontmost. Switched to the forceful ignoringOtherApps: true unconditionally, which doesn't exhibit the same failure and is appropriate for a direct, deliberate user click on our own menu item.