starred/komorebi
1
0
Fork 0
mirror of https://github.com/LGUG2Z/komorebi.git synced 2026-07-23 05:18:38 +02:00
Code Issues 87 Packages Projects Releases 11 Wiki Activity

[BUG]: Windows minimizing to the system tray sometimes keep their tile #410

New Issue
Closed
opened 2026-01-05 14:50:32 +01:00 by adam · 9 comments
adam commented 2026-01-05 14:50:32 +01:00
Owner
Copy Link
Copy Source

Originally created by @Insprill on GitHub (Jun 14, 2024).

Describe the bug
When some windows minimize to the system tray, they'll sometimes keep their tile, which can only by fixed by opening it and minimizing it again. I've had this happen with Unity Hub, WinGetUI, and Thunderbird.

To Reproduce
This bug is quite inconsistent, It doesn't happen every time, but it usually happens to me at least once daily.

  1. Open an application that can be minimized to the system tray.
  2. Get the application to go to the tray (opening a Unity project from Unity Hub, closing WinGetUI, or minimizing Thunderbird).
  3. A ghost tile will sometimes be left in its place, fully functional as if the window was still there, border and all.
  4. When opening the window again, it'll be placed in its tile as expected.

Expected behavior
The window tile should disappear with the window.

Operating System

OS Name:                   Microsoft Windows 11 Pro for Workstations
OS Version:                10.0.22631 N/A Build 22631

komorebic check Output

No KOMOREBI_CONFIG_HOME detected, defaulting to C:\Users\Insprill

Looking for configuration files in C:\Users\Insprill

Found komorebi.json; this file can be passed to the start command with the --config flag

No ~/.config/whkdrc found; you may not be able to control komorebi with your keyboard

Additional context
I don't have a copy of the komorebic state output, but the window does show there as if it was still open. I'll grab a copy of it next time it happens if it'll help.

Originally created by @Insprill on GitHub (Jun 14, 2024). **Describe the bug** When some windows minimize to the system tray, they'll sometimes keep their tile, which can only by fixed by opening it and minimizing it again. I've had this happen with Unity Hub, [WinGetUI](https://github.com/marticliment/WingetUI), and Thunderbird. **To Reproduce** This bug is quite inconsistent, It doesn't happen every time, but it usually happens to me at least once daily. 1. Open an application that can be minimized to the system tray. 2. Get the application to go to the tray (opening a Unity project from Unity Hub, closing WinGetUI, or minimizing Thunderbird). 3. A ghost tile will sometimes be left in its place, fully functional as if the window was still there, border and all. 4. When opening the window again, it'll be placed in its tile as expected. **Expected behavior** The window tile should disappear with the window. **Operating System** ``` OS Name: Microsoft Windows 11 Pro for Workstations OS Version: 10.0.22631 N/A Build 22631 ``` **`komorebic check` Output** ``` No KOMOREBI_CONFIG_HOME detected, defaulting to C:\Users\Insprill Looking for configuration files in C:\Users\Insprill Found komorebi.json; this file can be passed to the start command with the --config flag No ~/.config/whkdrc found; you may not be able to control komorebi with your keyboard ``` **Additional context** I don't have a copy of the `komorebic state` output, but the window does show there as if it was still open. I'll grab a copy of it next time it happens if it'll help.
adam added the bugkomorebi labels 2026-01-05 14:50:32 +01:00
adam closed this issue 2026-01-05 14:50:32 +01:00
adam commented 2026-01-05 14:50:32 +01:00
Author
Owner
Copy Link
Copy Source

@LGUG2Z commented on GitHub (Jun 14, 2024):

Sounds like they may need to be identified: https://lgug2z.github.io/komorebi/common-workflows/tray-and-multi-window-applications.html

If this works can you open a PR to the app specific config repo with the rules as well?

@LGUG2Z commented on GitHub (Jun 14, 2024): Sounds like they may need to be identified: https://lgug2z.github.io/komorebi/common-workflows/tray-and-multi-window-applications.html If this works can you open a PR to the app specific config repo with the rules as well?
adam commented 2026-01-05 14:50:32 +01:00
Author
Owner
Copy Link
Copy Source

@Insprill commented on GitHub (Jun 14, 2024):

I checked in my applications.yaml file, and Unity Hub and WinGetUI are both already there, and the executable names match. I'm not sure if that's the issue, considering it works most of the time; it's just occasionally that it doesn't.

@Insprill commented on GitHub (Jun 14, 2024): I checked in my `applications.yaml` file, and Unity Hub and WinGetUI are both already there, and the executable names match. I'm not sure if that's the issue, considering it works most of the time; it's just occasionally that it doesn't.
adam commented 2026-01-05 14:50:32 +01:00
Author
Owner
Copy Link
Copy Source

@LGUG2Z commented on GitHub (Jan 23, 2025):

@Insprill is this still an issue for you?

@LGUG2Z commented on GitHub (Jan 23, 2025): @Insprill is this still an issue for you?
adam commented 2026-01-05 14:50:33 +01:00
Author
Owner
Copy Link
Copy Source

@Insprill commented on GitHub (Jan 23, 2025):

Yes. Usually at least once every other day I have to check komorebic state to see which window is a ghost.

@Insprill commented on GitHub (Jan 23, 2025): Yes. Usually at least once every other day I have to check komorebic state to see which window is a ghost.
adam commented 2026-01-05 14:50:33 +01:00
Author
Owner
Copy Link
Copy Source

@LGUG2Z commented on GitHub (Jan 23, 2025):

I have just tried to reproduce this with both Thunderbird and UniGetUI, and the latest version of applications.json but I'm not able to 🤔

@LGUG2Z commented on GitHub (Jan 23, 2025): I have just tried to reproduce this with both Thunderbird and UniGetUI, and the latest version of `applications.json` but I'm not able to 🤔
adam commented 2026-01-05 14:50:33 +01:00
Author
Owner
Copy Link
Copy Source

@Insprill commented on GitHub (Jan 23, 2025):

I haven't found a reliable repro yet, it seems to happen at random. My theory is it might happen if other windows are opening/closing/minimizing at the same time (I know opening a window right after closing one will leave the new one unmanaged, haven't gotten around to writing a report for that yet 😅), but I haven't really tried to test it.

@Insprill commented on GitHub (Jan 23, 2025): I haven't found a reliable repro yet, it seems to happen at random. My theory is it might happen if other windows are opening/closing/minimizing at the same time (I know opening a window right after closing one will leave the new one unmanaged, haven't gotten around to writing a report for that yet 😅), but I haven't really tried to test it.
adam commented 2026-01-05 14:50:33 +01:00
Author
Owner
Copy Link
Copy Source

@LGUG2Z commented on GitHub (Jan 24, 2025):

I think I found a repro - I got this to happen reliably when a window on monitor 1 is focused, and then I try to close UniGetUI on monitor 2 by directly clicking the X button in the app bar without first otherwise focusing it's window

@LGUG2Z commented on GitHub (Jan 24, 2025): I think I found a repro - I got this to happen reliably when a window on monitor 1 is focused, and then I try to close UniGetUI on monitor 2 by directly clicking the X button in the app bar without first otherwise focusing it's window
adam commented 2026-01-05 14:50:33 +01:00
Author
Owner
Copy Link
Copy Source

@LGUG2Z commented on GitHub (Jan 24, 2025):

2025-01-24T00:18:54.369046Z DEBUG process_event{event="Hide" winevent="ObjectHide" hwnd=67876}:should_manage{self=Window { hwnd: 67876 } event=Some(Hide(ObjectHide, Window { hwnd: 67876 }))}
: komorebi::window: ignoring (exe: UniGetUI.exe, title: UniGetUI, event: Hide (WinEvent: ObjectHide, Window: (hwnd: 67876, title: UniGetUI, exe: UniGetUI.exe, class: WinUIDesktopWin32WindowClass)))

I can see here that the Hide event was ignored

@LGUG2Z commented on GitHub (Jan 24, 2025): ``` 2025-01-24T00:18:54.369046Z DEBUG process_event{event="Hide" winevent="ObjectHide" hwnd=67876}:should_manage{self=Window { hwnd: 67876 } event=Some(Hide(ObjectHide, Window { hwnd: 67876 }))} : komorebi::window: ignoring (exe: UniGetUI.exe, title: UniGetUI, event: Hide (WinEvent: ObjectHide, Window: (hwnd: 67876, title: UniGetUI, exe: UniGetUI.exe, class: WinUIDesktopWin32WindowClass))) ``` I can see here that the Hide event was ignored
adam commented 2026-01-05 14:50:33 +01:00
Author
Owner
Copy Link
Copy Source

@LGUG2Z commented on GitHub (Jan 24, 2025):

And it looks like this is only happening when the transparency feature is enabled 🤔

@LGUG2Z commented on GitHub (Jan 24, 2025): And it looks like this is only happening when the transparency feature is enabled 🤔
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
0.1.36
apps-behaving-badly
bug
bug
cannot-reproduce
documentation
enhancement
github_actions
i-am-stuck
i-will-definitely-work-on-this
i-will-not-work-on-this
i-will-probably-work-on-this
komorebi
komorebi-bar
komorebic
performance
pull-request
Mirrored from GitHub Pull Request
 translation
No labels bug komorebi
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
adam (Adam Melkus)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/komorebi#410