Originally created by @Insprill on GitHub (Jun 14, 2024).
Describe the bug
When focusing an application in another workspace, it will sometimes get stuck in an infinite workspace-switching loop that can only be stopped by killing komorebi and the application via task manager. It would appear that 07b2da69a1 didn't fully fix the issue. It's quite rare now; I've only had it happen twice in the last three weeks when Unity focuses on Rider (something that happens at least 50 times a day for me) but it does still happen.
To Reproduce
*see additional context
Open Unity and Rider on different workspaces.
Open a script in Unity so it focuses Rider.
Get lucky?
Expected behavior
Komorebi should not get stuck in a workspace-switching loop.
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've only had this happen when Unity focuses Rider (e.g., when opening a script), so it's possible the issue lies somewhere in there, but I find it more likely it's a general issue that only shows itself there due to how often that happens.
Originally created by @Insprill on GitHub (Jun 14, 2024).
**Describe the bug**
When focusing an application in another workspace, it will sometimes get stuck in an infinite workspace-switching loop that can only be stopped by killing komorebi *and* the application via task manager. It would appear that 07b2da69a1d132caaee1975752ef695a8ea15ce3 didn't fully fix the issue. It's quite rare now; I've only had it happen twice in the last three weeks when Unity focuses on Rider (something that happens at least 50 times a day for me) but it *does* still happen.
**To Reproduce**
*see additional context
1. Open Unity and Rider on different workspaces.
2. Open a script in Unity so it focuses Rider.
3. Get lucky?
**Expected behavior**
Komorebi should not get stuck in a workspace-switching loop.
**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've only had this happen when Unity focuses Rider (e.g., when opening a script), so it's possible the issue lies somewhere in there, but I find it more likely it's a general issue that only shows itself there due to how often that happens.
I think this will ultimately require some tuneable configuration parameters that can be set by the user, but for now when you do get hit with this bug you can probably hit alt-p to komorebic pause to get out of the loop
@LGUG2Z commented on GitHub (Jun 14, 2024):
I think this will ultimately require some tuneable configuration parameters that can be set by the user, but for now when you do get hit with this bug you can probably hit alt-p to komorebic pause to get out of the loop
@LGUG2Z commented on GitHub (Jun 19, 2024):
https://github.com/LGUG2Z/komorebi/commit/8bf4ab9f15fd8be6899117c549819080aadce648
This may have some impact on this issue
I'm experiencing this in a very reproducible manner with HoudiniFX (3D VFX QT application), I'll try Alt+P next time as only killing Komorebi works for now
@melMass commented on GitHub (Jul 20, 2024):
I'm experiencing this in a very reproducible manner with HoudiniFX (3D VFX QT application), I'll try Alt+P next time as only killing Komorebi works for now
I'm very regularly experiencing this when restarting komorebi and (manually) redistributing the windows over the various workspaces. I invariably reach a point where it will start looping through the workspaces, though I have not found a way to reliably reproduce. If it helps, the applications that are usually open are wezterm, outlook, edge, teams.
@rwijtvliet commented on GitHub (Nov 22, 2024):
I'm very regularly experiencing this when restarting komorebi and (manually) redistributing the windows over the various workspaces. I invariably reach a point where it will start looping through the workspaces, though I have not found a way to reliably reproduce. If it helps, the applications that are usually open are wezterm, outlook, edge, teams.
(manually) redistributing the windows over the various workspaces
Curious to know why setting initial_workspace_rules for the apps you always want to move to different workspaces on restart isn't an option 👀
@LGUG2Z commented on GitHub (Nov 22, 2024):
> (manually) redistributing the windows over the various workspaces
Curious to know why setting `initial_workspace_rules` for the apps you always want to move to different workspaces on restart isn't an option 👀
(manually) redistributing the windows over the various workspaces
Curious to know why setting initial_workspace_rules for the apps you always want to move to different workspaces on restart isn't an option 👀
Ah, I actually have those in place normally. I just temporarily removed them, because I thought they might be causing the issue. But turns out, the issue also arises when they are absent.
@rwijtvliet commented on GitHub (Nov 22, 2024):
> > (manually) redistributing the windows over the various workspaces
>
> Curious to know why setting `initial_workspace_rules` for the apps you always want to move to different workspaces on restart isn't an option 👀
Ah, I actually have those in place normally. I just temporarily removed them, because I thought they might be causing the issue. But turns out, the issue also arises when they are absent.
This may be helpful: on my machine a loop seems to only appear when multiple monitors are connected! They all show the same image. (the internal laptop monitor and 2 additional external ones).
I have not yet observed a loop if no external monitors are connected.
In the output above, I see several lines targeting distinct monitors - that might be a hint too. (focus_monitor{idx=2}: komorebi::window_manager: focusing monitor, but also with idx=1 and idx=0.)
@rwijtvliet commented on GitHub (Dec 3, 2024):
This may be helpful: on my machine a loop seems to only appear when **multiple monitors** are connected! They all show the same image. (the internal laptop monitor and 2 additional external ones).
I have not yet observed a loop if no external monitors are connected.
In the output above, I see several lines targeting distinct monitors - that might be a hint too. (`focus_monitor{idx=2}: komorebi::window_manager: focusing monitor`, but also with `idx=1` and `idx=0`.)
This might not be the exact same, but I had a slightly similar issue where the windows kept shuffling non stop in a loop. You can test this with "window_hiding_behaviour": "Minimize" and "window_container_behaviour": "Append" in the config and try stacking some windows together more detail in my other thread if interested.
@f34r1335 commented on GitHub (Feb 12, 2025):
This might not be the exact same, but I had a slightly similar issue where the windows kept shuffling non stop in a loop. You can test this with `"window_hiding_behaviour": "Minimize"` and `"window_container_behaviour": "Append"` in the config and try stacking some windows together [more detail in my other thread if interested](https://github.com/LGUG2Z/komorebi/discussions/1275).
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @Insprill on GitHub (Jun 14, 2024).
Describe the bug
When focusing an application in another workspace, it will sometimes get stuck in an infinite workspace-switching loop that can only be stopped by killing komorebi and the application via task manager. It would appear that
07b2da69a1didn't fully fix the issue. It's quite rare now; I've only had it happen twice in the last three weeks when Unity focuses on Rider (something that happens at least 50 times a day for me) but it does still happen.To Reproduce
*see additional context
Expected behavior
Komorebi should not get stuck in a workspace-switching loop.
Operating System
komorebic checkOutputAdditional context
I've only had this happen when Unity focuses Rider (e.g., when opening a script), so it's possible the issue lies somewhere in there, but I find it more likely it's a general issue that only shows itself there due to how often that happens.
@LGUG2Z commented on GitHub (Jun 14, 2024):
I think this will ultimately require some tuneable configuration parameters that can be set by the user, but for now when you do get hit with this bug you can probably hit alt-p to komorebic pause to get out of the loop
@LGUG2Z commented on GitHub (Jun 19, 2024):
https://github.com/LGUG2Z/komorebi/commit/8bf4ab9f15fd8be6899117c549819080aadce648
This may have some impact on this issue
@melMass commented on GitHub (Jul 20, 2024):
I'm experiencing this in a very reproducible manner with HoudiniFX (3D VFX QT application), I'll try Alt+P next time as only killing Komorebi works for now
@rwijtvliet commented on GitHub (Nov 22, 2024):
I'm very regularly experiencing this when restarting komorebi and (manually) redistributing the windows over the various workspaces. I invariably reach a point where it will start looping through the workspaces, though I have not found a way to reliably reproduce. If it helps, the applications that are usually open are wezterm, outlook, edge, teams.
@LGUG2Z commented on GitHub (Nov 22, 2024):
Curious to know why setting
initial_workspace_rulesfor the apps you always want to move to different workspaces on restart isn't an option 👀@rwijtvliet commented on GitHub (Nov 22, 2024):
Ah, I actually have those in place normally. I just temporarily removed them, because I thought they might be causing the issue. But turns out, the issue also arises when they are absent.
@rwijtvliet commented on GitHub (Nov 25, 2024):
Is there something I can do to help find the issue?
@rwijtvliet commented on GitHub (Dec 3, 2024):
I recorded the output of
komorebiduring one of the loops, maybe it is helpful in finding the source. Here is one second's worth:@rwijtvliet commented on GitHub (Dec 3, 2024):
This may be helpful: on my machine a loop seems to only appear when multiple monitors are connected! They all show the same image. (the internal laptop monitor and 2 additional external ones).
I have not yet observed a loop if no external monitors are connected.
In the output above, I see several lines targeting distinct monitors - that might be a hint too. (
focus_monitor{idx=2}: komorebi::window_manager: focusing monitor, but also withidx=1andidx=0.)@melMass commented on GitHub (Dec 3, 2024):
Dual monitor user too in case it matters!
@f34r1335 commented on GitHub (Feb 12, 2025):
This might not be the exact same, but I had a slightly similar issue where the windows kept shuffling non stop in a loop. You can test this with
"window_hiding_behaviour": "Minimize"and"window_container_behaviour": "Append"in the config and try stacking some windows together more detail in my other thread if interested.