mirror of
https://github.com/LGUG2Z/komorebi.git
synced 2026-01-11 14:40:25 +01:00
[BUG]: Unexpected behavior after enabling monocle mode on a window stack #343
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @RaptDept on GitHub (Apr 18, 2024).
Describe the bug
Enabling monocle mode on a stack of windows causes unexpected behavior:
komorebic promotewhile stuck in monocle mode will cause a panic.To Reproduce
Steps to reproduce the behavior:
komorebic promotewill cause a panic and komorebi will stop responding (this can also happen in step 3)Expected behavior
komorebic promoteshould probably do nothing but not cause a panic.Screenshots and Videos
Add screenshots and videos to help explain your problem.
Operating System
komorebic checkOutputAdditional context
@LGUG2Z commented on GitHub (Apr 18, 2024):
Repro'd by myself and @raggi earlier this week, but I can't remember if this was fixed on master or not yet.
@raggi commented on GitHub (Apr 19, 2024):
I believe this is https://github.com/LGUG2Z/komorebi/issues/758
I think the root cause is that now that we're sending ObjectDestroy messages down into process_event now - previously they would error in should_manage, which prevented any of those messages to be passed in at all (relying on reap to cleanup instead). This then raised a pre-existing but not-exercised bug where ObjectDestroy assumes that the object being destroyed is always in the "focsued workspace" / "focused container", which isn't always the case.
This is essentially a whole class of bug around event processing using
focused_*to route events. Another example in this class is the "invisible windows still affecting layout", like Discord frequently triggers. (Repro for discord is: open discord, focus another window in another workspace, hit the X on discord without focusing it - Komorebi won't correctly understand what changed, resulting a few different kinds of issue). Another class of this bug is: Open an unmanaged window, e.g. WhatsApp (without extra app definitions), which is layered and ignored. Focus a managed window, then drag whatsapp by title - the managed window will get moved when the drag completes.As a broad stroke we need to move away from "focused_*" for workspace/containers in event processing, instead we need to look at WindowsApi::foreground_window to get an HWND (which requires retries sometimes if the foreground window is mid-switch), then hunt for that HWND in the containers to perform container modifications. The general notion of "focused container" needs to be kept in sync with
WindowsApi::foreground_window(most events will need to check this for result - even ObjectFocus - as I've seen ObjectFocus,SystemForeground come in pointing at the wrong window (e.g. the stackbar windows create these, but never get focused/activated, and when those events arrive WindowsApi::foreground_window shows a different window being focused)). The notion of a focused container will then only be used to implement commands, and never to target or originate externally generated mutations (window drags, alt-tabs, click-to-focus changes, etc).@LGUG2Z commented on GitHub (Apr 20, 2024):
Closing as a dupe, will track work on #758