[BUG]: When starting Komorebi with minimized windows they are not managed

[allora]

Describe the bug When i start komorebi and have some windows minimized, komorebi will not manage the minimized window and i have no idea how to make it do so without first stopping komorebi and unminimizing everything and starting it again.

To Reproduce Steps to reproduce the behavior:

1. Stop komorebi
2. Minimize a window
3. Start Komorebi
4. See bug

Expected behavior I expected all windows to be included in the tile management

Screenshots and Videos I can add these if needed

Operating System Provide the output of systeminfo | grep "^OS Name\|^OS Version"

OS Name:                   Microsoft Windows 10 Pro
OS Version:                10.0.19045 N/A Build 19045

komorebic check Output Provide the output of komorebic check

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

Looking for configuration files in C:\Users\Allie

No komorebi configuration found in C:\Users\Allie

If running 'komorebic start --await-configuration', you will manually have to call the following command to begin tiling: komorebic complete-configuration

Additional context Pretty much a default basic setup as described in the readme. No additional window placement tools or hotkey daemons

This is a multi monitor setup

[LGUG2Z]

This is definitely strange behaviour - could you attach a video of this? I've tried to trigger this with various windows but have not been successful. Is this behaviour specific to a group of windows/applications for you, or does it happen with all windows/apps?

It would also be helpful if you can get komorebic log running on a terminal while you reproduce it for the video and share those logs.

[allora]

Here is the video and the log it created

https://github.com/LGUG2Z/komorebi/assets/12771565/bc4831a7-73de-49e1-9d15-8d72ba7df350

komorebic.log

[allora]

OH sorry forgot to mention: This happens when i change desktops on any of my monitors, it doesnt really matter what application is there, as you can see in the video its notepad in this case. But when i switch desktops alt acts like its held, so modifies what keypresses mean for that app.

[Insprill]

I can reliably reproduce this for most applications that Komorebi previously had cloaked. Reproducing is as easy as:

1. Move an application to workspace 2.
2. Go to workspace 1 and kill Komorebi.
3. Start Komorebi.
4. Refocus the application from the taskbar.

I've recorded a video showcasing this happening with bs-manager, an Electron application. I've been able to successfully reproduce it with several other applications made with Electron and Unity. However, as seen in the video, I've not been able to reproduce it with Firefox. You can also see that Komorebi isn't sure what to do with the window border when interacting with one of these bugged windows.

https://github.com/LGUG2Z/komorebi/assets/52843537/c46a78b5-b232-44b9-b952-a3fa0aa6efec

[LGUG2Z]

@Insprill thanks for sharing this video which clearly shows what's happening with the logs in the background!

https://github.com/LGUG2Z/komorebi/blob/3370e6acc55dc57a541819adb282de5134dd9d0c/komorebi/src/process_event.rs#L587

Uncloak is currently deliberately unmanaged which is why you're seeing this behaviour; I too come up against this sporadically with Electron apps, and the workaround I am using for now is to minimize and restore to force the system to send the restore event instead of the uncloak event.

I'll brainstorm if there are any heuristics we might be able to use to allow us to handle this specific subset of uncloak events.

[allora]

Huh, sorry i didnt even realize that for whatever reason my uploaded video wasnt playable x_x Glad you got one (right clicking and saving as does seem to work tho)

[LGUG2Z]

I believe this was fixed here: https://github.com/LGUG2Z/komorebi/commit/07b2da69a1d132caaee1975752ef695a8ea15ce3