[BUG]: Stackbar and border stop rendering after screen lock

[GaussianWonder]

Describe the bug

Occasionally the stackbar and border generated by komorebi vanish. The space designated for them is still there, they just don't render. I am unsure what causes this, but I think it currently happens when the computer sleeps, logs off, or whenever the screen lock appears.

Retiling does not help, I need to restart komorebi. Everything else works as expected.

To Reproduce

Unfortunately this might not be applicable for everybody

1. Start komorebi
2. Stack some windows
3. Lock screen
4. See bug, missing stackbar and borders

Operating System

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

komorebic retile and komorebic reload-configuration do not help.

[CtByte]

@GaussianWonder You might want to add that "Short descriptive title" 🙂

[GaussianWonder]

I did not notice that, thank you @CtByte

[LGUG2Z]

Just tried reproducing this both with Win+L to lock and by putting the computer to sleep from the start menu and I was not able to 🤔

[CtByte]

When I have some sort of issue with borders, I minimize my windows (usually with the "Show desktop" button at the far right of the Windows bar, next to the clock) and when I restore them then Komorebi "picks up" the windows and things get fixed.

Not sure if this works for others, but if it happens again, worth giving it a try, @GaussianWonder

[olw0905]

I have also observed bugs after screen lock. I have two monitors. If I lock the screen and wait for a while until the screens are off and all bluetooth devices are disconnected, and when I log in, the windows that were on the secondary monitor before screen lock are moved to the primary monitor (see the screenshot). Sometimes I can still see empty borders on the secondary monitor.

[LGUG2Z]

The monitor issue is a little bit separate, but I'll add some comments here:

All of the monitor handling code was separated into a standalone module earlier this year.

Unfortunately the documentation around messages relating to monitor events is incomplete at best, without even going into the non-standard behaviour that can result from specific virtual monitor (and maybe even physical monitor?) configurations.

I have exhausted all the possible combinations of messages that can be handled with all variations of monitor setups I can put together with the hardware I have available, so if you'd like to dig further into this, I'll ref the code block below where you can start adding debug logs to see which messages are and aren't being sent on your setup (or maybe there are additional messages being sent that aren't currently handled?)

https://github.com/LGUG2Z/komorebi/blob/45a5941872d60ffb375d56bf03af2280fb23f9e3/komorebi/src/monitor_reconciliator/mod.rs#L23-L31

The handlers for the system messages emit notifications that generally break up into 2 categories: notifications that stop the monitor reconiliator (so that windows don't get moved around during temporary disconnects etc.), and notifications that restart the monitor reconciliator.

https://github.com/LGUG2Z/komorebi/blob/45a5941872d60ffb375d56bf03af2280fb23f9e3/komorebi/src/monitor_reconciliator/hidden.rs#L104-L200

It is quite an involved but rewarding process if you can crack your issue, however as a work around you can probably run komorebic toggle-pause before you lock your screen and that should stop all system message processing, including for monitor and power events, until you toggle it back on.