macOS 14.4.1: Settings no longer orders front when activated

[tgrushka]

Bug Description, Steps to Reproduce, Crash Logs, Screenshots, etc.

Thanks for the great package! I'm using this in my MagicMac app (https://github.com/dra11y/MagicMac) that I use (depend on) daily for accessibility as a developer on my Mac, because well, Apple's speech on demand, invert colors, and other "accessibility" features for low vision users have evolved little since OS X 1.0. I often need to bring the Settings to the front to edit my custom speech text replacements.

Unfortunately, it appears Apple broke (what else is new?) ordering the window to the front, as I just updated to 14.4.1 last night and now, when I click on Settings in my Menu Extra, it appears nothing happens but the Settings window pops up behind everything else. This is really, really annoying. I tried deleting my Caches and $TMPDIR folders and rebooting. I tried rebuilding (Xcode 15.3), which partially fixes it (sometimes comes to the front, but not with VSCode or Chrome active, for example).

Is there any way you could check this out and see if it's possible to force-order-front the Settings window?

[orchetect]

Might be a SwiftUI bug, or a change in behavior (hopefully not though).

Does your app run as a dockless menubar app? You may need to call NSApp.activate first to give your app frontmost focus. That might help.

The demo app does it this way using the custom SettingsLink wrapper init:

SettingsAccess/Demo/Demo/DemoApp.swift

Lines 37 to 44 in e1083e6

	SettingsLink {
	Text("Settings...")
	} preAction: {
	// code to run before Settings opens
	NSApp.activate(ignoringOtherApps: true) // this does nothing if running from Xcode, but running as a standalone app it will work
	} postAction: {
	// code to run after Settings opens
	}

[tgrushka]

Thank you so much!! This code now works for me:

SettingsLink {
    Text("Settings")
} preAction: {
    NSApp.activate(ignoringOtherApps: true)
} postAction: {
    for window in NSApplication.shared.windows {
        if window.level == NSWindow.Level.popUpMenu {
            window.close()
            break
        }
    }
}

(For some reason, I was using the openSettingsAccess() injection method before, but SettingsLink now works for me.) EDIT: Could not get SettingsLink to close the popup before, but now works with postAction.

I think the culprit was: for window in NSApplication.shared.windows.... The reason for this code is that it was not closing the menu extra popup when I clicked on Settings. I tried again and confirmed that this code is required in my case. (Why can't SwiftUI just handle that? I think the whole focus is on iOS/watchOS and now the overpriced VR goggles; SwiftUI macOS bugs are taking a back seat. Steve Jobs is rolling his eyes...)

But, problem solved!! The settings window now comes to front, and I don't have to hide all my other windows to get back to it. Man, keeping up with all these frameworks' quirks on different platforms is really something else.

[orchetect]

closing the menu extra popup when I clicked on Settings
Why can't SwiftUI just handle that?

I assume you're using a window-based MenuBarExtra? SwiftUI will not auto-dismiss the window since it doesn't inherently know when you'd want to. Definitely a huge issue/shortcoming with MenuBarExtra, and yes it seems another symptom of macOS being second-class citizen to Apple's mobile platforms. There is no native way to dismiss the window programmatically other than the user clicking outside of the window. I built another package called MenuBarExtraAccess that can provide programmatic access to showing/dismissing the window - maybe it will help. But it sounds like your solution may be adequate for your situation.