search

steam3d / MagicPods-Windows

Add little magic to your Airpods
https://magicpods.app
304 stars 11 forks source link

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

Open stamminator opened 1 week ago

stamminator commented 1 week ago

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.

Animation

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 commented 1 week ago

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 commented 1 week ago

@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 commented 1 week ago

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

stamminator commented 1 week ago

@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.

Animation

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

steam3d commented 1 week ago

@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 commented 1 week ago

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 commented 1 week ago

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