Tray menu spawns multiple instances which don't disappear until MagicPods is closed

[stamminator]

When "bring taskbar to front" mode is active (which I've documented here), the state of the MagicPods context menu gets "disconnected" from the app's state, causing multiple instances to hang around indefinitely until the MagicPods process is closed.

Having no knowledge of the code base, my hunch is that the tray menu is not being managed as a singleton. Additionally, most apps seem to have trouble when "BTTF" mode (not sure what else to call it) is active while their tray menu is opened, but the one app I've seen that handles it best is Monitorian. It may be worth checking out how they do event handling for their tray menu.

[steam3d]

Hi. It's not a tray menu; it's an entire window. I set the property 'TopMost=True'. The window will close when it receives a deactivated event.

Since 'TopMost' works randomly and for privacy reasons, I do not globally catch mouse clicks and keyboard presses to force the window to close when the user clicks outside of it.

[stamminator]

@steam3d If I'm understanding correctly, it sounds like there's no way to avoid at least one of these menus from being "orphaned" while in BTTF mode without globally listening to M/KB events, which is why most apps don't handle it. Seems like an issue in Windows itself.

As for multiple instances of this menu existing simultaneously, when a user right-clicks the tray icon, couldn't you do a search for existing windows and close them before opening a new one?

[steam3d]

@stamminator Yes, I will close the current window if the user requests a new one.

[stamminator]

@steam3d As my recording shows, that isn't always the case. It's easy enough to reproduce that I frequently run into it after opening the Action Center to enable bluetooth and the right-clicking MagicPods to check on its connection status.

Once it's in this state, it stops closing prior windows, and only terminating MagicPods fixes the problem.

[steam3d]

@stamminator I know. It's a known issue. As I said above, I cannot globally catch user input due to privacy concerns to fix this.

[stamminator]

So, it looks like there are two separate issues here.

The first is that certain states in Windows (what I'm calling BTTF, but there may be others) cause menus opened from tray icons while in this state to stop receiving deactivated events. This results in each app's menu getting "orphaned" until the user once again interacts with the tray icon while no longer in this BTTF state, which I document here. While it is possible to listen to global M/KB events as a workaround (which might be what Monitorian does, but I'm not sure), this introduces privacy concerns and puts the ball in Microsoft's court to fix.

The second issue is different and I believe a legitimate bug in MagicPods. Multiple tray menu instances should not be able to exist simultaneously. While the Windows bug is a scenario under which this defect can take place, other apps successfully avoid this without global event listening by doing a manual check for existing windows within their app's process and not relying entirely on Windows-emitted deactivate events. Regardless of what caused a window to get orphaned, once the user manually clicks on an app's tray icon again, that app has full control to terminate orphaned windows within its own process without any need to listen to global events. Therefore it is fixable.

[steam3d]

@stamminator I will fix the second issue in future updates.