Window frozen on workspace switch #22

New Issue

Closed

opened 2026-01-05 14:47:45 +01:00 by adam · 5 comments

adam commented 2026-01-05 14:47:45 +01:00

Owner

Copy Link

Copy Source

Originally created by @openclosure on GitHub (Aug 26, 2021).

I'm noticing an issue with my simple setup so I'm wondering if I'm doing something wrong.

• I have a single monitor.
• I have Google-Chrome, Windows Terminal, and a few explorer windows open on workspace 1.
• On workspace 2 I have a single window of VS Code.

Issue Description:

Starting from Workspace 1, when returning to Workspace 2 via Alt+2, the VS Code window is visually frozen and won't respond to mouse or keyboard until I hit Alt+Tab (even if I'm Alt+Tabbing to nothing), then the window starts looking and behaving normally. One interesting aspect is that whatever mouse/keyboard commands I issued while it was frozen will be reflected upon unfreeze. So it's truly like visual buffer of the window is frozen but the underlying application is receiving and responding to inputs just fine.

Steps to replicate:

Simple way:

1. Start on workspace 2.
2. Switch to workspace 1 via Alt+1
3. Switch back to workspace 2 via Alt+2
4. Issue is present

One more specific way I've found to replicate the issue more consistently is:

1. Open a new window or change the layout (even remove a window) on WS 1.
2. After changing the layout but without explicitly focusing on anything with the mouse, switch to WS 2 with Alt+2.
3. The issue will be present.
4. If I open a second window on WS 2, the issue will no longer happen.

• This also happens if VS Code and Google-Chrome are switched between WS 1 and 2.
• If there is a second window on WS 2, I can also "unfreeze" by clicking that window (will be frozen), then clicking VS Code. In fact, having more than 1 window on each workspace basically prevents the issue from occuring.

My AHK script is nearly identical to the sample provided except I changed the line for focus-follows-mouse to:

Run, komorebic.exe focus-follows-mouse disable, , Hide

Here is the output of the logs, starting from WS 2, and simply executing Alt+1, Alt+2, and then Alt+Tab to unfreeze the window. Let me know what other information I can provide.

Awesome project btw, despite this issue, loving it so far.

Aug 25 23:52:54.409  INFO read_commands:process_command{FocusWorkspaceNumber(0)}:focus_workspace{idx=0}: komorebi::window_manager: focusing workspace
Aug 25 23:52:54.410  INFO read_commands:process_command{FocusWorkspaceNumber(0)}:focus_workspace{idx=0}:focus_workspace{idx=0}: komorebi::monitor: focusing workspace
Aug 25 23:52:54.631  INFO read_commands:process_command{FocusWorkspaceNumber(0)}:focus_workspace{idx=0}:update_focused_workspace{mouse_follows_focus=true}: komorebi::window_manager: updating
Aug 25 23:52:54.664  INFO read_commands:process_command{FocusWorkspaceNumber(0)}: komorebi::process_command: processed
Aug 25 23:52:54.665  INFO process_event{event=Show(ObjectShow, Window { hwnd: 198468 })}:focus_monitor{idx=0}: komorebi::window_manager: focusing monitor
Aug 25 23:52:54.666  INFO process_event{event=Show(ObjectShow, Window { hwnd: 198468 })}: komorebi::process_event: processed: (hwnd: 198468, title: LGUG2Z/komorebi: A tiling window manager for Windows - Google Chrome, exe: chrome.exe, class: Chrome_WidgetWin_1)
Aug 25 23:52:54.667  INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 198468 })}:focus_monitor{idx=0}: komorebi::window_manager: focusing monitor
Aug 25 23:52:54.667  INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 198468 })}:focus_window{idx=0}: komorebi::container: focusing window
Aug 25 23:52:54.668  INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 198468 })}:focus_container{idx=0}: komorebi::workspace: focusing container
Aug 25 23:52:54.668  INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 198468 })}: komorebi::process_event: processed: (hwnd: 198468, title: LGUG2Z/komorebi: A tiling window manager for Windows - Google Chrome, exe: chrome.exe, class: Chrome_WidgetWin_1)
Aug 25 23:52:54.669  INFO process_event{event=Show(ObjectShow, Window { hwnd: 460394 })}:focus_monitor{idx=0}: komorebi::window_manager: focusing monitor
Aug 25 23:52:54.670  INFO process_event{event=Show(ObjectShow, Window { hwnd: 460394 })}: komorebi::process_event: processed: (hwnd: 460394, title: Windows PowerShell, exe: WindowsTerminal.exe, class: CASCADIA_HOSTING_WINDOW_CLASS)
Aug 25 23:52:54.671  INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 460394 })}:focus_monitor{idx=0}: komorebi::window_manager: focusing monitor
Aug 25 23:52:54.671  INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 460394 })}:focus_window{idx=0}: komorebi::container: focusing window
Aug 25 23:52:54.672  INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 460394 })}:focus_container{idx=1}: komorebi::workspace: focusing container
Aug 25 23:52:54.672  INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 460394 })}: komorebi::process_event: processed: (hwnd: 460394, title: Windows PowerShell, exe: WindowsTerminal.exe, class: CASCADIA_HOSTING_WINDOW_CLASS)
Aug 25 23:52:54.674  INFO process_event{event=Show(ObjectShow, Window { hwnd: 788350 })}:focus_monitor{idx=0}: komorebi::window_manager: focusing monitor
Aug 25 23:52:54.676  INFO process_event{event=Show(ObjectShow, Window { hwnd: 788350 })}: komorebi::process_event: processed: (hwnd: 788350, title: C:\Users\etrip, exe: explorer.exe, class: CabinetWClass)
Aug 25 23:52:54.678  INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 788350 })}:focus_monitor{idx=0}: komorebi::window_manager: focusing monitor
Aug 25 23:52:54.678  INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 788350 })}:focus_window{idx=0}: komorebi::container: focusing window
Aug 25 23:52:54.679  INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 788350 })}:focus_container{idx=2}: komorebi::workspace: focusing container
Aug 25 23:52:54.679  INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 788350 })}: komorebi::process_event: processed: (hwnd: 788350, title: C:\Users\etrip, exe: explorer.exe, class: CabinetWClass)
Aug 25 23:52:54.680  INFO process_event{event=Show(ObjectShow, Window { hwnd: 395450 })}:focus_monitor{idx=0}: komorebi::window_manager: focusing monitor
Aug 25 23:52:54.681  INFO process_event{event=Show(ObjectShow, Window { hwnd: 395450 })}: komorebi::process_event: processed: (hwnd: 395450, title: C:\Users\etrip\AppData\Local\Microsoft\WindowsApps, exe: explorer.exe, class: CabinetWClass)
Aug 25 23:52:54.683  INFO process_event{event=Hide(ObjectHide, Window { hwnd: 657642 })}: komorebi::process_event: processed: (hwnd: 657642, title: komorebi.log - ffopt - Visual Studio Code, exe: Code.exe, class: Chrome_WidgetWin_1)
Aug 25 23:52:56.082  INFO read_commands:process_command{FocusWorkspaceNumber(1)}:focus_workspace{idx=1}: komorebi::window_manager: focusing workspace
Aug 25 23:52:56.084  INFO read_commands:process_command{FocusWorkspaceNumber(1)}:focus_workspace{idx=1}:focus_workspace{idx=1}: komorebi::monitor: focusing workspace
Aug 25 23:52:56.186  INFO read_commands:process_command{FocusWorkspaceNumber(1)}:focus_workspace{idx=1}:update_focused_workspace{mouse_follows_focus=true}: komorebi::window_manager: updating
Aug 25 23:52:56.190  INFO read_commands:process_command{FocusWorkspaceNumber(1)}: komorebi::process_command: processed
Aug 25 23:52:56.195 ERROR komorebi::process_event: there is no window
Aug 25 23:52:56.204  INFO process_event{event=Hide(ObjectHide, Window { hwnd: 460394 })}: komorebi::process_event: processed: (hwnd: 460394, title: Windows PowerShell, exe: WindowsTerminal.exe, class: CASCADIA_HOSTING_WINDOW_CLASS)
Aug 25 23:52:56.209 ERROR komorebi::process_event: there is no window
Aug 25 23:52:56.212  INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 395450 })}:focus_monitor{idx=0}: komorebi::window_manager: focusing monitor
Aug 25 23:52:56.215 ERROR komorebi::process_event: there is no container/window
Aug 25 23:52:56.219 ERROR komorebi::process_event: there is no window
Aug 25 23:52:56.222  INFO process_event{event=Show(ObjectShow, Window { hwnd: 657642 })}:focus_monitor{idx=0}: komorebi::window_manager: focusing monitor
Aug 25 23:52:56.226  INFO process_event{event=Show(ObjectShow, Window { hwnd: 657642 })}: komorebi::process_event: processed: (hwnd: 657642, title: komorebi.log - ffopt - Visual Studio Code, exe: Code.exe, class: Chrome_WidgetWin_1)
Aug 25 23:52:56.234  INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 657642 })}:focus_monitor{idx=0}: komorebi::window_manager: focusing monitor
Aug 25 23:52:56.235  INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 657642 })}:focus_window{idx=0}: komorebi::container: focusing window
Aug 25 23:52:56.236  INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 657642 })}:focus_container{idx=0}: komorebi::workspace: focusing container
Aug 25 23:52:56.237  INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 657642 })}: komorebi::process_event: processed: (hwnd: 657642, title: komorebi.log - ffopt - Visual Studio Code, exe: Code.exe, class: Chrome_WidgetWin_1)
Aug 25 23:53:00.187  INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 657642 })}:focus_monitor{idx=0}: komorebi::window_manager: focusing monitor
Aug 25 23:53:00.188  INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 657642 })}:focus_window{idx=0}: komorebi::container: focusing window
Aug 25 23:53:00.189  INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 657642 })}:focus_container{idx=0}: komorebi::workspace: focusing container
Aug 25 23:53:00.190  INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 657642 })}: komorebi::process_event: processed: (hwnd: 657642, title: komorebi.log - ffopt - Visual Studio Code, exe: Code.exe, class: Chrome_WidgetWin_1)

Originally created by @openclosure on GitHub (Aug 26, 2021). I'm noticing an issue with my simple setup so I'm wondering if I'm doing something wrong. - I have a single monitor. - I have Google-Chrome, Windows Terminal, and a few explorer windows open on workspace 1. - On workspace 2 I have a single window of VS Code. **Issue Description:** Starting from Workspace 1, when returning to Workspace 2 via `Alt+2`, the VS Code window is visually frozen and won't respond to mouse or keyboard until I hit `Alt+Tab` (even if I'm `Alt+Tabbing` to nothing), then the window starts looking and behaving normally. One interesting aspect is that whatever mouse/keyboard commands I issued while it was frozen will be reflected upon unfreeze. So it's truly like visual buffer of the window is frozen but the underlying application is receiving and responding to inputs just fine. **Steps to replicate:** Simple way: 1. Start on workspace 2. 2. Switch to workspace 1 via `Alt+1` 3. Switch back to workspace 2 via `Alt+2` 4. Issue is present One more specific way I've found to replicate the issue more consistently is: 1. Open a new window or change the layout (even remove a window) on WS 1. 2. After changing the layout but without explicitly focusing on anything with the mouse, switch to WS 2 with `Alt+2`. 3. The issue will be present. 4. If I open a second window on WS 2, the issue will no longer happen. * This also happens if VS Code and Google-Chrome are switched between WS 1 and 2. * If there is a second window on WS 2, I can also "unfreeze" by clicking that window (will be frozen), then clicking VS Code. In fact, having more than 1 window on each workspace basically prevents the issue from occuring. My AHK script is nearly identical to the sample provided except I changed the line for `focus-follows-mouse` to: `Run, komorebic.exe focus-follows-mouse disable, , Hide` Here is the output of the logs, starting from WS 2, and simply executing `Alt+1`, `Alt+2`, and then `Alt+Tab` to unfreeze the window. Let me know what other information I can provide. Awesome project btw, despite this issue, loving it so far. ``` Aug 25 23:52:54.409 INFO read_commands:process_command{FocusWorkspaceNumber(0)}:focus_workspace{idx=0}: komorebi::window_manager: focusing workspace Aug 25 23:52:54.410 INFO read_commands:process_command{FocusWorkspaceNumber(0)}:focus_workspace{idx=0}:focus_workspace{idx=0}: komorebi::monitor: focusing workspace Aug 25 23:52:54.631 INFO read_commands:process_command{FocusWorkspaceNumber(0)}:focus_workspace{idx=0}:update_focused_workspace{mouse_follows_focus=true}: komorebi::window_manager: updating Aug 25 23:52:54.664 INFO read_commands:process_command{FocusWorkspaceNumber(0)}: komorebi::process_command: processed Aug 25 23:52:54.665 INFO process_event{event=Show(ObjectShow, Window { hwnd: 198468 })}:focus_monitor{idx=0}: komorebi::window_manager: focusing monitor Aug 25 23:52:54.666 INFO process_event{event=Show(ObjectShow, Window { hwnd: 198468 })}: komorebi::process_event: processed: (hwnd: 198468, title: LGUG2Z/komorebi: A tiling window manager for Windows - Google Chrome, exe: chrome.exe, class: Chrome_WidgetWin_1) Aug 25 23:52:54.667 INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 198468 })}:focus_monitor{idx=0}: komorebi::window_manager: focusing monitor Aug 25 23:52:54.667 INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 198468 })}:focus_window{idx=0}: komorebi::container: focusing window Aug 25 23:52:54.668 INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 198468 })}:focus_container{idx=0}: komorebi::workspace: focusing container Aug 25 23:52:54.668 INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 198468 })}: komorebi::process_event: processed: (hwnd: 198468, title: LGUG2Z/komorebi: A tiling window manager for Windows - Google Chrome, exe: chrome.exe, class: Chrome_WidgetWin_1) Aug 25 23:52:54.669 INFO process_event{event=Show(ObjectShow, Window { hwnd: 460394 })}:focus_monitor{idx=0}: komorebi::window_manager: focusing monitor Aug 25 23:52:54.670 INFO process_event{event=Show(ObjectShow, Window { hwnd: 460394 })}: komorebi::process_event: processed: (hwnd: 460394, title: Windows PowerShell, exe: WindowsTerminal.exe, class: CASCADIA_HOSTING_WINDOW_CLASS) Aug 25 23:52:54.671 INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 460394 })}:focus_monitor{idx=0}: komorebi::window_manager: focusing monitor Aug 25 23:52:54.671 INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 460394 })}:focus_window{idx=0}: komorebi::container: focusing window Aug 25 23:52:54.672 INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 460394 })}:focus_container{idx=1}: komorebi::workspace: focusing container Aug 25 23:52:54.672 INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 460394 })}: komorebi::process_event: processed: (hwnd: 460394, title: Windows PowerShell, exe: WindowsTerminal.exe, class: CASCADIA_HOSTING_WINDOW_CLASS) Aug 25 23:52:54.674 INFO process_event{event=Show(ObjectShow, Window { hwnd: 788350 })}:focus_monitor{idx=0}: komorebi::window_manager: focusing monitor Aug 25 23:52:54.676 INFO process_event{event=Show(ObjectShow, Window { hwnd: 788350 })}: komorebi::process_event: processed: (hwnd: 788350, title: C:\Users\etrip, exe: explorer.exe, class: CabinetWClass) Aug 25 23:52:54.678 INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 788350 })}:focus_monitor{idx=0}: komorebi::window_manager: focusing monitor Aug 25 23:52:54.678 INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 788350 })}:focus_window{idx=0}: komorebi::container: focusing window Aug 25 23:52:54.679 INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 788350 })}:focus_container{idx=2}: komorebi::workspace: focusing container Aug 25 23:52:54.679 INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 788350 })}: komorebi::process_event: processed: (hwnd: 788350, title: C:\Users\etrip, exe: explorer.exe, class: CabinetWClass) Aug 25 23:52:54.680 INFO process_event{event=Show(ObjectShow, Window { hwnd: 395450 })}:focus_monitor{idx=0}: komorebi::window_manager: focusing monitor Aug 25 23:52:54.681 INFO process_event{event=Show(ObjectShow, Window { hwnd: 395450 })}: komorebi::process_event: processed: (hwnd: 395450, title: C:\Users\etrip\AppData\Local\Microsoft\WindowsApps, exe: explorer.exe, class: CabinetWClass) Aug 25 23:52:54.683 INFO process_event{event=Hide(ObjectHide, Window { hwnd: 657642 })}: komorebi::process_event: processed: (hwnd: 657642, title: komorebi.log - ffopt - Visual Studio Code, exe: Code.exe, class: Chrome_WidgetWin_1) Aug 25 23:52:56.082 INFO read_commands:process_command{FocusWorkspaceNumber(1)}:focus_workspace{idx=1}: komorebi::window_manager: focusing workspace Aug 25 23:52:56.084 INFO read_commands:process_command{FocusWorkspaceNumber(1)}:focus_workspace{idx=1}:focus_workspace{idx=1}: komorebi::monitor: focusing workspace Aug 25 23:52:56.186 INFO read_commands:process_command{FocusWorkspaceNumber(1)}:focus_workspace{idx=1}:update_focused_workspace{mouse_follows_focus=true}: komorebi::window_manager: updating Aug 25 23:52:56.190 INFO read_commands:process_command{FocusWorkspaceNumber(1)}: komorebi::process_command: processed Aug 25 23:52:56.195 ERROR komorebi::process_event: there is no window Aug 25 23:52:56.204 INFO process_event{event=Hide(ObjectHide, Window { hwnd: 460394 })}: komorebi::process_event: processed: (hwnd: 460394, title: Windows PowerShell, exe: WindowsTerminal.exe, class: CASCADIA_HOSTING_WINDOW_CLASS) Aug 25 23:52:56.209 ERROR komorebi::process_event: there is no window Aug 25 23:52:56.212 INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 395450 })}:focus_monitor{idx=0}: komorebi::window_manager: focusing monitor Aug 25 23:52:56.215 ERROR komorebi::process_event: there is no container/window Aug 25 23:52:56.219 ERROR komorebi::process_event: there is no window Aug 25 23:52:56.222 INFO process_event{event=Show(ObjectShow, Window { hwnd: 657642 })}:focus_monitor{idx=0}: komorebi::window_manager: focusing monitor Aug 25 23:52:56.226 INFO process_event{event=Show(ObjectShow, Window { hwnd: 657642 })}: komorebi::process_event: processed: (hwnd: 657642, title: komorebi.log - ffopt - Visual Studio Code, exe: Code.exe, class: Chrome_WidgetWin_1) Aug 25 23:52:56.234 INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 657642 })}:focus_monitor{idx=0}: komorebi::window_manager: focusing monitor Aug 25 23:52:56.235 INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 657642 })}:focus_window{idx=0}: komorebi::container: focusing window Aug 25 23:52:56.236 INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 657642 })}:focus_container{idx=0}: komorebi::workspace: focusing container Aug 25 23:52:56.237 INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 657642 })}: komorebi::process_event: processed: (hwnd: 657642, title: komorebi.log - ffopt - Visual Studio Code, exe: Code.exe, class: Chrome_WidgetWin_1) Aug 25 23:53:00.187 INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 657642 })}:focus_monitor{idx=0}: komorebi::window_manager: focusing monitor Aug 25 23:53:00.188 INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 657642 })}:focus_window{idx=0}: komorebi::container: focusing window Aug 25 23:53:00.189 INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 657642 })}:focus_container{idx=0}: komorebi::workspace: focusing container Aug 25 23:53:00.190 INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 657642 })}: komorebi::process_event: processed: (hwnd: 657642, title: komorebi.log - ffopt - Visual Studio Code, exe: Code.exe, class: Chrome_WidgetWin_1) ```

adam closed this issue 2026-01-05 14:47:45 +01:00

adam commented 2026-01-05 14:47:45 +01:00

Author

Owner

Copy Link

Copy Source

@crosstyan commented on GitHub (Aug 26, 2021):

I have encountered the same problem. I think it a problem shared with all the Chromium based application like Electron, which VSCode bases on. When I was using other tiling window manager like workspacer I also encountered the same problem.

I'm not sure if the issue in workspacer is the same problem, but it worth mentioning.

You can try to repro this by only place one Chromium window on workspace, but not every time this problem will appear.

The window will be unfreeze if you move the window a little bit, or minimize and restore the window. But the window will go blank if you maximize the window.

@crosstyan commented on GitHub (Aug 26, 2021): I have encountered the same problem. I think it a problem shared with all the Chromium based application like Electron, which VSCode bases on. When I was using other tiling window manager like workspacer I also encountered the same problem. I'm not sure if [the issue in workspacer](https://github.com/workspacer/workspacer/issues/171) is the same problem, but it worth mentioning.  You can try to repro this by only place one Chromium window on workspace, but not every time this problem will appear. The window will be unfreeze if you move the window a little bit, or minimize and restore the window. But the window will go blank if you maximize the window.

adam commented 2026-01-05 14:47:45 +01:00

Author

Owner

Copy Link

Copy Source

@LGUG2Z commented on GitHub (Aug 26, 2021):

This is ultimately a Chromium + Electron bug that we had a discussion on at length back in the yatta days. Basically it boils down to Chromium not respecting the native ShowWindow API on Windows and handling window hiding and restoring through their own JS BrowserWindow API.

I don't use any Electron apps so I don't come across this behaviour, but back when I was trying to debug this on yatta the quickest thing to do was to run the retile command whenever you see the issue (the same effect as Alt-Tab).

Since the codebase for komorebi is a lot cleaner I have a few ideas for hacks that might be able to address this on a strictly opt-in basis.

I'm thinking that on workspace switch, we can see if the workspace contains any windows with the Electron class Chrome_WidgetWin_1, and if it does, once the workspace layout has been applied, a separate thread can wait for 1s (or whatever the minimum required time is for a redraw to correct the Electron rendering bug; we already learned that it doesn't work if you run two commands in succession either in the process or in AHK), and then force a redraw of those windows.

I'll spend some time in the coming days to see if this is possible and if it can help with the issue. Time to install Chrome again... 🙈

@LGUG2Z commented on GitHub (Aug 26, 2021): This is ultimately a Chromium + Electron bug that we [had a discussion on at length back in the yatta days](https://github.com/LGUG2Z/yatta/pull/15#issuecomment-883276827). Basically it boils down to Chromium not respecting the native [`ShowWindow`](https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-showwindow) API on Windows and handling window hiding and restoring through their own JS `BrowserWindow` API. I don't use any Electron apps so I don't come across this behaviour, but back when I was trying to debug this on `yatta` the quickest thing to do was to run the `retile` command whenever you see the issue (the same effect as Alt-Tab). Since the codebase for `komorebi` is a lot cleaner I have a few ideas for hacks that might be able to address this on a strictly opt-in basis. I'm thinking that on workspace switch, we can see if the workspace contains any windows with the Electron class `Chrome_WidgetWin_1`, and if it does, once the workspace layout has been applied, a separate thread can wait for 1s (or whatever the minimum required time is for a redraw to correct the Electron rendering bug; we already learned that it doesn't work if you run two commands in succession either in the process or in AHK), and then force a redraw of those windows. I'll spend some time in the coming days to see if this is possible and if it can help with the issue. Time to install Chrome again... 🙈

adam commented 2026-01-05 14:47:45 +01:00

Author

Owner

Copy Link

Copy Source

@LGUG2Z commented on GitHub (Aug 26, 2021):

I'm thinking that on workspace switch, we can see if the workspace contains any windows with the Electron class Chrome_WidgetWin_1, and if it does, once the workspace layout has been applied, a separate thread can wait for 1s (or whatever the minimum required time is for a redraw to correct the Electron rendering bug; we already learned that it doesn't work if you run two commands in succession either in the process or in AHK), and then force a redraw of those windows.

I just tried this approach this morning and unfortunately, when reproducing this, I notice that the freezing doesn't actually occur (and so can't be "fixed") until the window itself is interacted with after the workspace switch. 😞

At this point I can only encourage people to open bugs on the Electron, Chromium and VSCode repositories to try to get this fixed upstream in Chromium.

I will leave this issue open in this repo just in case anyone is able to come up with a hack that might help with this behaviour in the meantime, but I'm afraid that the only remedy to this issue for now is to Alt-Tab unfreeze your frozen Electron apps.

@LGUG2Z commented on GitHub (Aug 26, 2021): > I'm thinking that on workspace switch, we can see if the workspace contains any windows with the Electron class `Chrome_WidgetWin_1`, and if it does, once the workspace layout has been applied, a separate thread can wait for 1s (or whatever the minimum required time is for a redraw to correct the Electron rendering bug; we already learned that it doesn't work if you run two commands in succession either in the process or in AHK), and then force a redraw of those windows. I just tried this approach this morning and unfortunately, when reproducing this, I notice that the freezing doesn't actually occur (and so can't be "fixed") until the window itself is interacted with after the workspace switch. 😞 At this point I can only encourage people to open bugs on the Electron, Chromium and VSCode repositories to try to get this fixed upstream in Chromium. I will leave this issue open in this repo just in case anyone is able to come up with a hack that might help with this behaviour in the meantime, but I'm afraid that the only remedy to this issue for now is to Alt-Tab unfreeze your frozen Electron apps.

adam commented 2026-01-05 14:47:45 +01:00

Author

Owner

Copy Link

Copy Source

@LGUG2Z commented on GitHub (Feb 14, 2022):

While trying to replicate https://github.com/LGUG2Z/komorebi/issues/110 I realised that this behaviour does not occur on my machine with komorbeic window-hiding-behaviour minimize set. Can anyone who has experienced this issue before report back on their experiences using the minimize window behaviour behaviour option?

@LGUG2Z commented on GitHub (Feb 14, 2022): While trying to replicate https://github.com/LGUG2Z/komorebi/issues/110 I realised that this behaviour does not occur on my machine with `komorbeic window-hiding-behaviour minimize` set. Can anyone who has experienced this issue before report back on their experiences using the `minimize` window behaviour behaviour option?

adam commented 2026-01-05 14:47:46 +01:00

Author

Owner

Copy Link

Copy Source

@M-Agha commented on GitHub (Feb 27, 2022):

Setting the window-hiding-behavior to minimize does fix the freezing of vscode for me.

@M-Agha commented on GitHub (Feb 27, 2022): Setting the `window-hiding-behavior` to `minimize `does fix the freezing of vscode for me.

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

master

dependabot/cargo/sysinfo-0.39.5

dependabot/cargo/shadow-rs-2.0.0

dependabot/cargo/egui_extras-0.35.0

dependabot/cargo/eframe-0.35.0

dependabot/github_actions/actions/checkout-7

dependabot/cargo/serde_with-3.19.0

dependabot/github_actions/softprops/action-gh-release-3

dependabot/github_actions/actions/github-script-9

dependabot/cargo/reqwest-0.13.2

dependabot/cargo/sysinfo-0.38.0

feature/default_workspace_layout

gh-pages

feature/stack-force-disable-transparency

feature/multi-monitor-scrolling

feature/floating-over-monocle

feature/spawn-loc

nightly

v0.1.41

v0.1.40

v0.1.39

v0.1.38

v0.1.37

v0.1.36

v0.1.35

v0.1.34

v0.1.33

v0.1.32

v0.1.31

v0.1.30

v0.1.29

v0.1.28

v0.1.27

v0.1.26

v0.1.25

v0.1.24

v0.1.23

v0.1.22

v0.1.21

v0.1.20

v0.1.19

v0.1.18

v0.1.17

v0.1.16

v0.1.15

v0.1.14

v0.1.13

v0.1.12

v0.1.11

v0.1.10

v0.1.9

v0.1.8

v0.1.7

v0.1.6

v0.1.5

v0.1.4

v0.1.3

v0.1.2

v0.1.1

v0.1.0

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

Milestone

No items

No Milestone

Projects

Clear projects

No projects

Assignees

Clear assignees

adam (Adam Melkus)

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/komorebi#22