Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Focus is not restored after hiding Guake when using Marco #1816

Closed
andreymal opened this issue Dec 5, 2020 · 5 comments
Closed

Focus is not restored after hiding Guake when using Marco #1816

andreymal opened this issue Dec 5, 2020 · 5 comments

Comments

@andreymal
Copy link

Steps to reproduce:

  1. Run X11 with Marco window manager (a part of MATE Desktop Environment)
  2. Open some window so that it has focus
  3. Open Guake
  4. Hide Guake using shortcut (F12 by default)

Expected behavior: focus should be given to the window that was in focus before Guake was opened

Actual behavior: focus is given to the X11 root window (in other words, no real window is focused, which leads to various glitches until I click somewhere)

I discovered some strange things:

  • When using Openbox, Metacity or Mutter everything works fine. So this may be a Marco bug, but I don't know how to reliably check it.
  • When using guake-toggle everything works fine even with Marco. So could this be a Guake shortcut bug?
  • When I press Ctrl+D to exit shell and thus close last Guake tab, everything works fine.

I'm not sure if this is a Guake bug because other window managers work fine. However, I don't know how to make a minimal reproducible example to reproduce similar problem with Marco and without using Guake, so I am trying to write it here and would be grateful for any hints on this.

Guake Version: 3.7.0
Vte Version: 0.62.1
Vte Runtime Version: 0.62.1
GTK+ Version: 3.24.23
GDK Backend: GdkX11.X11Display
Desktop Session: mate
Marco Version: 1.24.1
RGBA visual: True
Composited: True/False (does not matter)

There is a gif showing the problem. I'm using xdotool to get the currently focused window, and when Guake hides its window, the focus is given to window 530 which is a root window.

@andreymal
Copy link
Author

I am not seeing this issue on Ubuntu 20.04 (Guake 3.6.3, Marco 1.24.0). Assuming that patch version of Marco shouldn't break something, it looks like a bug in Guake 3.7.0 (but I'm still not sure)

@Davidy22
Copy link
Collaborator

Davidy22 commented Sep 5, 2021

Did a quick search on the marco repo and it looks like the focus behavior being different from other desktop environments is an intentional feature that makes focus follow your mouse pointer instead of the last window you had open. Since this is intentional on part of the marco devs, we will not attempt to override their desired desktop behavior and you'll need to petition your preference to them.

@Davidy22 Davidy22 closed this as completed Sep 5, 2021
@andreymal
Copy link
Author

Oh, I just noticed that Guake immediately hides by pressing any global hotkey from any other GTK (but not Qt) application. Strange things are happening...

@Davidy22
Copy link
Collaborator

There's now an option in guake settings for lazy lose focus, so if other programs are only snatching focus momentarily guake will not hide if you turn it on. It does mean guake won't hide when you do anything that only takes focus for an instant, like workspace switching, but if it suits your preference you can opt into it.

@andreymal
Copy link
Author

The marco "feature" seems to be fixed, but I'm still experiencing this issue.

The "Lazy hide on lose focus" option doesn't help.

According to my current experiments, the focus is not restored if the toggle hotkey is still pressed after Guake hides its window. If the hotkey is released fast enough, the focus is successfully restored. This is very difficult to reproduce it with a human finger, but it's possible to use a superhuman script:

xdotool keydown --delay 0 F12 keyup --delay 0 F12

When using this command instead of pressing the real button, there is ~95% chance that the focus will be successfully restored

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants