fuhsjr00 / bug.n

Tiling Window Manager for Windows
GNU General Public License v3.0
3.36k stars 214 forks source link

[Incompatibility] Activation of Electron/Chromium apps #279

Open porridgewithraisins opened 3 years ago

porridgewithraisins commented 3 years ago

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.

GIF 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

joten commented 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.

Gorkido commented 3 years ago

i also have the same thing

porridgewithraisins commented 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.

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.

porridgewithraisins commented 3 years ago

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?

jsjoeio commented 2 years ago

I'm getting the same issue while using VS Code in the browser

image

porridgewithraisins commented 2 years ago

I'm getting the same issue while using VS Code in the browser

image

Hi, you can try using the fix I mentioned above It works just fine.

jsjoeio commented 2 years ago

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:

  1. Go this PR and copy the changes to your local bug.n directory
  2. Make sure you have AutoHotkey installed (download here)
  3. Run bug.n from the script by opening Main.ahk with AutoHotkey
  4. Rejoice!