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

Changing focused space doesn't actually change focus #229

Closed
chandlerc opened this issue Sep 2, 2019 · 5 comments
Closed

Changing focused space doesn't actually change focus #229

chandlerc opened this issue Sep 2, 2019 · 5 comments
Labels
help wanted Community help appreciated question Request for information or help, not an issue undetermined Not sure if this is considered a real bug

Comments

@chandlerc
Copy link

I tried to check for other issues, but they seemed different.

Reproduction steps:

  1. Open a Chrome window on both display images #1 and display migrating from chunkWM #2 as the only windows in their spaces
  2. Open some other application (kitty in my case) on a different space on display migrating from chunkWM #2 (the "previous" space in my case)
  3. Focus the Chrome spaces (and windows) on both displays
  4. While focused on the Chrome window on display migrating from chunkWM #2
  5. Send yabai -m space --focus prev via keyboard

I would expect this to change the space on display #2 and focus on the only window in the new space (kitty in my case). Everything but the focus works (display #2 moves to the previous space where the kitty window is visible). However, it reliably sends the focus to the other still-visible Chrome window which is on display #1.

FWIW, Mojave, scripting extensions are enabled, and i'm using a homebrew install from head.

@dominiklohmann
Copy link
Collaborator

dominiklohmann commented Sep 2, 2019

Because of lessons learned from its predecessors, yabai does never change window focus from window focused events. The flickering is a really bad experience. When switching spaces, macOS focuses the application that was most recently active on that space instead of a window on that space.

As a workaround, you can focus the target window on the space before switching spaces.

# instead of: yabai -m space --focus prev
yabai -m window --focus "$(yabai -m query --spaces --space prev | jq -r '."last-window"')" \
    || yabai -m space --focus prev

# instead of: yabai -m space --focus next
yabai -m window --focus "$(yabai -m query --spaces --space next | jq -r '."first-window"')" \
    || yabai -m space --focus next

The space query attributes first-window / last-window hold the window ids of the first and last tiled window on that space.

What's really missing here is a recent-window attribute for the most recently focused window on any space, and maybe the space focus command should default to focusing such a window if available.

Edit:

  • Added missing --focus in the command.
  • There's a bug with this: If another window of the same application as the window focused by id was most recently active on the target space, two windows look as if they're active. Here's a screenshot

image

@koekeishiya
Copy link
Owner

This feels like something that should be considered a bug. Will take a closer look at this when I have time.

@koekeishiya
Copy link
Owner

koekeishiya commented Sep 2, 2019

So I tried to reproduce using the steps you've given. I'll re-list the steps here to make sure I did not misunderstand anything.

  1. Open Chrome as the sole window of the active space of Display 1.
  2. Open some other application on the first space of Display 2 (Kitty in my case, v0.14.1 - not sure if that matters).
  3. Open another Chrome window as the only window on the next space of Display 2, such that the one containing Kitty is the previous one.
  4. Make the space with Chrome active on both Display 1 and 2, with focus given to the window on Display 2.
  5. Issue yabai -m space --focus prev using keyboard shortcut.

When I do the above, Kitty does become the active application and window for me, which is in line with what I expected with regards to how the code is written. The issue you are having is very likely because of the macOS most recently focused behaviour as described by @dominiklohmann

I'm not sure I'd classify this as a bug, but I very much agree that this is an annoyance and it would be great if there was a clean way to solve this problem. As of now, a solution here will require further experimentation.

@koekeishiya
Copy link
Owner

Seems like I missed an earlier issue that seems to be very much the same as this one - see #160

@koekeishiya koekeishiya added help wanted Community help appreciated undetermined Not sure if this is considered a real bug question Request for information or help, not an issue labels Sep 3, 2019
@chandlerc
Copy link
Author

Sorry I've not had time to do more digging.

So, I thought I figured out the extra step that caused this... but I think I was wrong.

Here was what I hoped would be correct:

  1. Open Chrome as the sole window of the active space of Display 1.
  2. Open some other application on the first space of Display 2 (Kitty in my case, v0.14.1 - not sure if that matters).
  3. Open another Chrome window on the first space of Display 2 (same as the kitty window)
  4. Move that Chrome window to the next space of Display 2, it should now also be focused and Display 2 should be on its space.
  5. Issue yabai -m space --focus prev using keyboard shortcut, expecting it to go back to the previous space of Display 2 where the Kitty window should be focused.

And then it goes to the Chrome window on Display 1.

This then makes sense with @dominiklohmann's explanation: when moving to the previous space on Display 2, the previously focused application on that display is Chrome, and there is a visible Chrome window (over on Display 1), so focus is sent there.

Sadly, this didn't reproduce for me.

But there is some sequence that triggers this. It keeps happening to me, about once or twice a day. I've yet to successfully retrace the sequence of steps though. I'll keep trying and update this bug if I succeed.

That said, here are a bunch of thoughts I had about how to potentially overcome the issue Dominik explained (if in fact that is what I'm hitting and I've just not replicated the steps to hit it correctly..):

One way would be to do what Dominik suggested and force focus a specific window on the target space rather than leaving it unspecified. However, there seems to be some bugs there.

An option that would be nice (and close to Dominik's most recently focused window idea) is if you could query for the application most recently used on the space (the one macOS will target when moving to that space) and check if there are any windows from that application on the target space. If so, do what happens today. If not, pick the first window and focus that first before switching spaces.

Another option which would work fine for me: when moving a window from one space to another, first de-focus that window in favor of any other window on its current space (the next one, the previous one, the first one all seem fine; you could even try to find a window from the same application to more closely replicate the macOS behavior when compatible). Then move the window to the new space and re-focus it after it moves. This will essentially ensure that the most-recently-focused application for any given space remains one with a window open in that space. When moving the last window out of a space, first focus the finder/desktop thing, and then move the window.

Anyways, I'll see if I can stumble onto this and get a reproducer. Sorry for the noise so far.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Community help appreciated question Request for information or help, not an issue undetermined Not sure if this is considered a real bug
Projects
None yet
Development

No branches or pull requests

3 participants