mirror of
https://github.com/LGUG2Z/komorebi.git
synced 2026-01-11 14:40:25 +01:00
Window frozen on workspace switch #22
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 @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.
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 hitAlt+Tab(even if I'mAlt+Tabbingto 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:
Alt+1Alt+2One more specific way I've found to replicate the issue more consistently is:
Alt+2.My AHK script is nearly identical to the sample provided except I changed the line for
focus-follows-mouseto:Run, komorebic.exe focus-follows-mouse disable, , HideHere is the output of the logs, starting from WS 2, and simply executing
Alt+1,Alt+2, and thenAlt+Tabto unfreeze the window. Let me know what other information I can provide.Awesome project btw, despite this issue, loving it so far.
@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.
@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
ShowWindowAPI on Windows and handling window hiding and restoring through their own JSBrowserWindowAPI.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
yattathe quickest thing to do was to run theretilecommand whenever you see the issue (the same effect as Alt-Tab).Since the codebase for
komorebiis 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):
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 (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 minimizeset. Can anyone who has experienced this issue before report back on their experiences using theminimizewindow behaviour behaviour option?@M-Agha commented on GitHub (Feb 27, 2022):
Setting the
window-hiding-behaviortominimizedoes fix the freezing of vscode for me.