Open porridgewithraisins opened 3 years ago
By the looks of the title bar -- the window is not activated at all, which may be the case, if the last active window of the view is not set or falsely set. You may try resetting bug.n by restarting it without the window and layout states saved.
i also have the same thing
By the looks of the title bar -- the window is not activated at all, which may be the case, if the last active window of the view is not set or falsely set. You may try resetting bug.n by restarting it without the window and layout states saved.
Thanks for addressing the issue. I will try to reset bug.n.
It doesn't seem to happen with VS Code anymore. Only happens with chrome browsers these days. I tried to find a pattern as to when it happened, with no luck.
It even happens sometimes when closing a browser tab and the browser switches back to the previous one. I checked if the config rules for chrome browsers, which the documentation said dealt with a tab-recognized-as-window problem, was set just like the documentation showed, and it was. So I am not entirely sure why the problem is arising.
However, calling the window information in that in-between state where the browser doesn't render stuff, shows the correct window is active.
Perhaps a hidden window of the browser is remembered as the last active window of the view? But then, clicking the window title in the bug.n status bar in that in-between state, activates it normally, and from my poking around in the source, clicking on the window title in the status bar seems to activate the same window that is remembered as the last active window of the view.
UPDATE: Well, I just had a random idea and edited Window.ahk like so:
Window_activate(wndId) {
If Window_isHung(wndId) {
Debug_logMessage("DEBUG[2] Window_activate: Potentially hung window " . wndId, 2)
Return, 1
} Else {
WinActivate ahk_class Progman ;CHANGE: activate progman, then the window
WinActivate, ahk_id %wndId%
WinGet, aWndId, ID, A
If (wndId != aWndId)
Return, 1
Else
Return, 0
}
}
Progman is the window that is active on the desktop. And I noticed that when I switched from a non-empty view (desktop is the active window), the problem didn't happen, so I'm doing that every time. Hacky, but it seems to do the trick. I've used it for the last half hour, and it seems to work fine. I'll test it more in the coming days, and write again here
UPDATE: It seems to work properly with this edit, should I make a PR?
I'm getting the same issue while using VS Code in the browser
I'm getting the same issue while using VS Code in the browser
Hi, you can try using the fix I mentioned above It works just fine.
Hi, you can try using the fix I mentioned above It works just fine.
Oh right silly me. Okay posting how I did it in case it helps others:
This is now happening with edge, chrome, VS-code.
When switching from a view with a non empty set of windows, to a view which has the main window as edge/brave/vscode/chromium browsers, the window doesn't seem to respond to certain input immediately. Rather, I need to interact with or focus the window in a different way in order to see the changes.
You can see that wheel down, wheel up, and keyboard input is sent to the window, but the window doesn't reflect the changes until it is activated in a non-bug.n way