Moving to a Chrome window changes focus to other Chrome window on another monitor

[AlDrag]

This may be a MacOS problem that can't be solved.

How to reproduce

1. Open up a chrome window on both monitors.
2. While having a Chrome window open on one monitor, navigate away from the Chrome window using PaperWM.spoon.
3. When navigating back to the Chrome window, MacOS changes focus to the Chrome window on the other monitor.

Obviously it would be nice if it didn't change focus to the other monitor, but again, I think this is core MacOS problem.

[mogenson]

Hello, I got a second monitor to try this out, but I can't seem to duplicate it. I created a Chrome window on Monitor 1 and Monitor 2 (which is Mission Control Space 1 and Mission Control Space 2) along with some other application windows.

I used the PaperWM.spoon keyboard shortcuts to change focus between the Chrome window and other windows on Space 1.

I used the PaperWM.spoon keyboard shortcuts to change focus between the Chrome window and other windows on Space 2.

I used the mouse to change focus between the Chrome window and other windows on Space 1.

I used the mouse to change focus between the Chrome window and other windows on Space 2.

When selected with mouse or keyboard, focus always returned to the Chrome window on the active Space.

Perhaps something has changed with recent versions of Hammerspoon, Macos, or Chrome. My current setup is:
Chrome: 115.0.5790.114
MacOS: 13.5
Hammerspoon: 0.9.100

[AlDrag]

Interesting. I will retry and see if I can reproduce.

It's always been a problem for me when navigating between desktops instead of using PaperWM.spoon.

Very possible I just haven't configured PaperVM.spoon properly (regarding MacOS display/window management settings).

Edit: Really appreciate you testing it. Thanks.

[mogenson]

I tried adding some behavior to find a window to focus before switching to a new Mission Control space. Would you like to try it out in this branch and see if helps your Chrome window issue at all? https://github.com/mogenson/PaperWM.spoon/tree/focus-window-before-switching-space

[AlDrag]

@mogenson so tested this with a Chrome and VSCode window open on 1 screen, and again a Chrome and VSCode window on another screen.

For some reason I can get into a state where I can move the tiles on both screens at once with the keyboard.

Just confirmed I can still reproduce the original issue on your master branch as well.
Let me know if there is any debugging I can do for you.

[AlDrag]

Seems like it may all be related to this issue: Hammerspoon/hammerspoon#370

[mogenson]

That was an informative read! I'll try out the raise app then focus window technique to see if it helps. Spawning hidden windows may be an overkill solution for PaperWM.spoon.

[mogenson]

I pushed a new commit to the https://github.com/mogenson/PaperWM.spoon/tree/focus-window-before-switching-space branch to raise an application before focusing it's window in a new space. See if this behavior performs any better for you. From my testing, there are still some times when switching between spaces (especially spaces where there are windows of the same app, ie Chrome) when a window on the new space is not focused. As a work around, I've noticed that if I press the switch to space keyboard shortcut again, a window will be selected and focused the second time.

[AlDrag]

@mogenson I think that's working much better! I will need to give it more time to see how it goes. I will use it throughout work for the next couple of days.

So in regards to your caveat, is that the issue where it seems to move both spaces at the same time? (assuming a space is a monitor/screen).

So for example:

1. on monitor1 (space1) I navigate with keyboard commands just fine.
2. I think use my mouse to select a window in space2 (the other monitor).
3. When trying to navigate to a different window in that new space using the keyboard commands, it will move to the next window in the other space as well, but only for the first navigation.

Hard to demonstrate without a video. Maybe I can try find a solution to record both monitors at the same time if needed.

Edit: It seems my switchToSpace command just opens up the mission control view (where it zooms out and shows all windows). But it doesn't allow me to switch to a new space at all 🤔
This is unrelated to this issue, as it has always been a problem for me.

Edit2: Hmmm using it further, it seems to be a lot worse than expected. Somehow I have windows that aren't navigable via keyboard commands etc. I might try help diagnose by playing with the code.

[mogenson]

Sorry to hear that. If there are stability issues I won't merge this branch into main.

I have ⌘1 mapped to switch to space 1. Sometimes when I press that shortcut, the space will switch but a window will not be focused in space 1. I've noticed that if I press ⌘1 again, now a window will be focused in space 1.

[AlDrag]

I have ⌘1 mapped to switch to space 1. Sometimes when I press that shortcut, the space will switch but a window will not be focused in space 1. I've noticed that if I press ⌘1 again, now a window will be focused in space 1.

Does that shortcut not clash with switching tabs in a browser? (e.g. in Chrome, ⌘1 will switch to tab 1).

[mogenson]

I have a specific PaperWM.spoon layer for keyboard shortcuts. But that shouldn't affect how the switchToSpace() method works.

[mogenson]

I know there's still some issues with multiple monitors, but I'm going to merge the commits from https://github.com/mogenson/PaperWM.spoon/tree/focus-window-before-switching-space as part of #15. They've been working reasonably well for me for the past few weeks. If there's any catastrophic bugs or crashes I'll go in and revert them.

[AlDrag]

@mogenson apologies for the lack of response, but no problem! :) Thanks for being active.

The refresh idea in your latest commit might actually be super useful to me. Will give it a go.

[jessevdp]

Hey! I'm running into this issue too. Was this ever merged and released?

If I "focus left/right" onto a Safari window while having a Safari window open on my second display it focuses that one instead.

This kind of "steals" the whole focus away into that separate space.

[mogenson]

@jessevdp Could you try out the commit in PR #53 and let me know if it improves the window focus stealing problem in Applications like Chrome / Safari?

[mogenson]

PR #53 works well enough for me. I haven't seen Chrome steal a window focus back. Closing this as fixed for now.

[jessevdp]

Hey, sorry for getting back to you so late.
I just had some time to check it out, seems to work wonders!

Was this merged to the release branch BTW? I'm kind of an Hammerspoon noob and am using Spooninstall to get PaperWM.spoon installed. Re-loading my config didn't seem to "fix" the issue. After I pointed Spooninstall to the main branch it seems like reloading the config installed the patch for me.

[mogenson]

PR #53 is in the release branch as of Oct 20: https://github.com/mogenson/PaperWM.spoon/commits/release/

There's a CI action to make a new zip bundle on the release branch whenever a commit is merged into the main branch.

Is there a way to force Spoon.install to fetch a new zip bundle?