Problematic focus shift in dual monitor setup

[jangroth]

First of all, I'd like to thank you for implementing this extension. It's one of my most important plugins and I have organized my complete work setup around having workspaces in a matrix! :green_heart:

I'd like to report a problem that only occurs in dual-monitor setup:

Setup:

• Two monitors, workspaces on primary display only.
• Primary display: App X and Y on different workspaces. Secondary display: App Z
• Focus on App X

Action:

• Shift workspaces to get from App X to App Y

Expectation:

• App Y (primary display) holds focus

Problem:

• App Z (secondary display) holds focus.

Or, in simpler words: When switching between two apps on different workspaces, the focus gets transferred to an unrelated app on another display.

This is problematic as the focus shift is completely unexpected. Muscle-memory operations like 'shift to App Y and trigger F5' end up on the wrong application, despite App Y sitting right in front of me on the screen. Even worse: 'Move to a new workspace and close existing apps with Alt-F4'.

Also, this is not convenient to work-around, the only way to give focus to the target app is cycling through Alt-tab, which can take a while and is not always straightforward if similar applications (browsers, IDEs) are open.

If I disable wsmatrrix and use vanilla gnome-shell workspace-switching the issue does not occur and the focus always ends up on the target workspace.

I'm happy to provide more information if required.

[mzur]

Thanks for the report. I noticed this behavior, too, but never thought that it might be caused by this extension. In fact, what I found is that this behavior is likely the same than that of the vanilla workspaces and only appears different. Here is what you can try to test this:

1. Configure a 2x2 grid of workspaces.
2. Open apps on both the top workspaces and the bottom right workspace, as well as one on the other monitor.
3. Switch to the top left workspace, focus the app, then switch to the top right workspace and focus the app. Now the apps should stay focussed when you switch between the two workspaces instead of focussing the app in the other monitor.
4. Now switch to the top right workspace and then down to the bottom right workspace. This switch will always focus the app on the other monitor.

My guess why the app on the other monitor is focussed here is that by switching from the top right workspace to the bottom right, GNOME "virtually" passes over the bottom left workspace (as if they were still linear) and by doing so, focusses the app on the other monitor because the bottom left workspace is empty. You can confirm this by disabling this extension. Here you should end up with four linear workspaces where the first two and the last contain apps. If you switch from the first to the last, the app on the other monitor is focussed once you pass over the empty workspace, and stays focussed.

I'm not sure if this behavior can be changed/fixed by this extension. But I agree that it probably would make sense. Maybe even the default behavior can be considered faulty and this can be fixed in upstream GNOME.

[jangroth]

Thanks for getting back to me. Clearly, you have a much deeper understanding of how workspaces work than me :-)

I ran the tests that you suggested:

• Testing with enabled workspace extension 2x2 -> ... Now switch to the top right workspace and then down to the bottom right workspace. This switch will always focus the app on the other monitor.... :heavy_check_mark:
• Testing with disabled extensions -> ...if you switch from the first to the last, the app on the other monitor is focussed once you pass over the empty workspace, and stays focussed.... :heavy_check_mark: & :negative_squared_cross_mark:

Unfortunately, I don't get consistent behaviour for the test case with disabled extension:

• workspace 1 (app 1): start with app 1 focussed
• workspace 2 (app 2): hover over, app 2 receives focus
• workspace 3 (empty): hover over, app 3 on second monitor receives focus
• workspace 4 (app 4): app 4 receives focus if it's the same application than app 1&2 (e.g. firefox instances). app 3 will stay focussed if it's a different instance than app 1&2 (e.g. pdf viewer)

However, I should say that my knowledge about this is rudimentary at best. E.g. it could well be that it's not the type of the app that influences the behaviour but the point in time when the app on the other screen has been opened. (pdf viewer has been open for hours, firefox just for this test). Or maybe there's an internal queue of when apps were last focussed (this might make sense for cycling through apps with alt+tab)?

Another observation: With enabled extension, in a 3x3 matrix, with apps on top left, top center and other screen, the app on the other screen is already getting focussed if I only hover from top left to top center. (I would have thought hovering over an empty workspace would be required to ever give focus to the other screen.)

[mzur]

Clearly, you have a much deeper understanding of how workspaces work than me :-)

Not really, I can only find things out by trial and error. There is no documentation for these kinds of things (or the entire GNOME JavaScript API for that matter) that I'm aware of.

You seem to be correct. The focussed window seems to be determined by some sort of queue of windows that were focussed last. If the window on the other monitor has been focussed (manually) more recently than any window on any workspace, it will get focus if switched to that workspace. If the workspace is empty, the window on the other monitor will get focus but won't change position in the queue. Can you confirm this? This seems to be at least some sort of consistent behavior.

[jangroth]

Yes, I think you are right. There seems to be a queue involved, and returning or keeping focus from the other screen is determined by the position of the other screen's application in the queue.

However, I just spent 30min or so trying to get consistent results with different approaches but failed.

I leave the table I started in this post, but I think the takeaway is that there are other factors contributing to the focus selection that we haven't understood.

Let me know if there's anything I can to help with that, but for now, am I right in assuming there's no easy fix fo this?

---

Here is my setup, when changes workspaces from top left to top right on a 3x3 matrix: t1 < t2 < t3, so t1 had focus before t2 had focus before t3

top left	top center	tor right	second screen	focus after hovering TL to TR
t3	.	t1	t2	second screen
t3	.	t2	t1	second screen
t1	.	t3	t2	second screen
t1	.	t2	t3	workspace matrix

---

[mzur]

Let me know if there's anything I can to help with that, but for now, am I right in assuming there's no easy fix fo this?

That's right. By now, I suspect that this behavior is not caused (or to be fixed) by this extension. You could ask in the GNOME repo what the expected behavior should be and/or propose an improvement.

[jangroth]

I've created this issue at the gnome-shell repo: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3641

I've posted a question on gnome discourse: https://discourse.gnome.org/t/expected-behaviour-of-application-focus-changes-in-workspaces-multi-monitor-setup/5552?u=jangroth

Hope someone is able to point me to the right direction.

[ebeem]

I think I should have noticed this long time ago, I never get the windows queue shuffled. I remember the order of my windows very well because I have a triple-monitor setup and 3 windows per workspace (one on each monitor). I never experienced an issue with the focus, if I switch back to workspace#7 after leaving it for days, I will still get the last order I had (unless I restart gnome or my system goes to sleep, etc.).

I don't think that there is anything in wsmatrix that will change the behavior of the focusing, can you please both confirm whether you use xorg or wayland? I still think wayland produces such unexpected results sometimes. So maybe try with xorg and see if you still get the same issue.

[mzur]

I use Xorg. Does your setup have workspaces on all monitors or only on one and the other two are single workspaces? I have a main monitor with workspaces and a second monitor with a single workspace. I believe the primary issue is that I expect the windows of the main monitor to be focused but the window on the second monitor gets focus when I switch workspaces.

[ebeem]

All of my monitors have workspaces enabled. so I don't use a single workspace on some monitors.

[jangroth]

Thanks for your responses - it's a tricky problem to describe. A one-sentence summary of the core problem:

In a multi-monitor setup, while shifting between workspaces, sometimes an unrelated app on a different monitor steals the focus and keeps it.

This is super annoying as it requires manually refocussing the application on the target workspace.

I've posted a question on gnome discourse but didn't receive a response. (https://discourse.gnome.org/t/expected-behaviour-of-application-focus-changes-in-workspaces-multi-monitor-setup/5552?u=jangroth)

My gut feel is this a gnome issue rather than a problem of wsmatrix, but there doesn't seem to be an easy path to even understanding the expected behaviour.

I've made my peace with it - happy for this issue to be closed :-)

[ebeem]

Thanks @jangroth, I too think this will be very annoying, but for some reason I have never experienced this issue before. Of course if it happened then most likely that's an upstream issue as wsmatrix doesn't play with the focus. I am still not sure why I am not facing this issue tho, my focused app's name will show up in my top menu. I can't see inconsistencies between workspaces switching. I am not sure if this is altered by some extensions. I use Alternatetab and I am configuring it to show only windows in the current workspace. The order of my windows and the focused window are always consistent, I never notice that the windows queue get shuffled.

[jangroth]

I am still not sure why I am not facing this issue

@ebeem - it could be a simple as this:

All of my monitors have workspaces enabled. so I don't use a single workspace on some monitors.

This might explain the difference. My setup uses workspaces on one monitor only (so that I can keep important apps like Slack on the other), and the interfering application always sits on that static workspace.

I assume this will run through different code paths when shifting focus for me than for you.

[mzur]

could be a simple as this:

All of my monitors have workspaces enabled. so I don't use a single workspace on some monitors.

That was my thought as well, we have a different setup. IIRC in my last test GNOME did behave consistently but not always as I would expect. It puts the focus on the most recently focused window (for each workspace, no matter what monitor). I would expect that it puts the focus on the most recently focused window on my main monitor. For me this issue is about the cases where the (consistent) behavior does not match my expectations.

[ebeem]

Alright, now I understand, I thought since this happens only on single workspaces then it might be the case. I gave it a quick test and it turned out that the behavior is actually consistent somehow if you know how gnome handles windows.

So in my case when I have workspaces span monitors I don't face this issue, the reason behind that is because every time I change my workspace, my entire local queue of windows focus order (you should be able to check it using alt+tab) gets changed. Of course in this case it becomes a subset of my global queue windows focus order (you should be able to check this using alt+`). This is totally fine when I span my workspaces across my monitors.

Now in your case, when you change your workspace only in one single monitor, your local queue of windows focus is not going to entirely change, it's going to be a mix between all current apps in all monitors, and it's going to be in the order of the last active window. I will try to make a simple test case. we have a setup with 1x2 workspaces and x2 monitors.

workspace#1
* monitor#1: VLC
* monitor#2: gnome-tweaks
workspace#2
* monitor#1: emacs

1- I am playing some music using VLC. 2- I switch to workspace#2 and I get the focus on emacs (expected) 3- I go back to workspace#1 and I get focus on VLC (expected) 4- I change focus to gnome-tweaks and then change it again to VLC. 5- I switch to workspace#2 again but I get focus on gnome-tweaks? (actually expected).

what happened in step#4 is that when I focused on gnome-tweaks, the global queue windows focus has the order of gnome-tweaks = 2, while the order of emacs = 3. Now if I switch to workspace#2 I will get focus on recently focused window (gnome-tweaks in this case). Maybe someone can test this and confirm it, I am not sure if it's the expected behavior or not. Maybe to fix this we need to change the focus to the most recent app in the current monitor in single workspace mode.

[jangroth]

Going with your example, I experience the problem in a slightly more complex setup:

workspace#1
* monitor#1: VLC
* monitor#2: gnome-tweaks (static)
workspace#2
* monitor#1: empty
* monitor#2: gnome-tweaks (static)
workspace#3
* monitor#1: firefox
* monitor#2: gnome-tweaks (static)

Shifting workspaces from workspace#1 to workspace#3, (on monitor#1 from VLC to firefox), while hovering over the empty workspace#2, gnome-tweaks will gain focus and not release it.

At least not always.

I've spent hours trying to find a system behind the unwanted behaviour, but couldn't get to the bottom of it. Hence my question on Gnome Discourse to understand the expected behaviour, but no response.

I guess it's a difficult setup that's hard to explain.

[ebeem]

I am not sure if I explained it well or not, but hovering shouldn't give focus to a window. Maybe try changing the workspaces without playing with the focus, just change workspace and see which window is being focused. If you are not getting consistent results then there is a problem.

About the focus that happened to gnome-tweaks in your case, depending on the state as described in the scenario above, it could happen. This is is my expectation of gnome's behavior.

setup

workspace#1
* monitor#1: VLC
* monitor#2: gnome-tweaks (static)
workspace#2
* monitor#1: empty
* monitor#2: gnome-tweaks (static)
workspace#3
* monitor#1: firefox
* monitor#2: gnome-tweaks (static)

scenario: 1- go to vlc in workspace#1 (focus it) 2- go to firefox in workspace#3 (focus it) (without passing by workspace#2) 3- switch to workspace#1 (without passing by workspace#2) vlc will get focused 4- switch to workspace#3 (without passing by workspace#2) firefox will get focused 5- switch to workspace#1 by passing through workspace#2 gnome-tweaks will get focused instead of vlc

So if you jump immediately to workspace#1 vlc will get focused, if you go through workspace#2 gnome-tweaks will get focused. Why? because in workspace#2 you will only have gnome-tweaks in your local windows and it will be focused automatically and will be the most recently focused app. This is actually not something that I accounted for in my previous suggested solution. I don't think that this can be easily solved because your empty workspace will cause somehow an expected but probably not desired behavior.

[jangroth]

I think there might be some source of confusion in the word hovering.

To get from workspace#1 to workspace#3, I

• long-press ctrl & alt
• press right arrow once (<- now I'm hovering over workspace#2)
• press right arrow again (not I'm over workspace#3)
• release ctrl & alt

In other words: There's no way for me to get from workspace#1 to workspace#3 without touching on workspace#2. I believe the intermediate 'focus steal' is correct, however, gnome-tweaks should release focus again when the motion has been completed and all keys released.

OTH, let's not take it too far here.

I have since learned that this is quite a specific problem that you would only experience in a dual-monitor/single-workspace setup. I believe the problem is most likely caused upstream and feel I did the right thing by trying to initialise a discussion on Gnome Discourse.

I'm happy to call it quits :-)

Thanks everyone for their help and input!

[ebeem]

@jangroth sorry, didn't notice you had some queries in here. You can move to workspaces immediately by clicking them from the switcher popup (GNOME 40) or by assigning keybindings to specific workspaces. For example, you can assign some keybindings to move to workspace#3 regardless which workspace you're current in. Below you can find a code block that will assign move to assign switch to workspace#3 and move to workspace#3. This will help in your case if you like the workflow.

gsettings set org.gnome.desktop.wm.keybindings switch-to-workspace-3 "['<Control><Alt>KP_3']" 
gsettings set org.gnome.desktop.wm.keybindings move-to-workspace-3 "['<Control><shift><Alt>KP_3']" 

However, I don't think that this will be resolved as there's no way to predict the expected behavior of the user for this problem. Please feel free to reopen in case you think we can mitigate the problem.