GNOME Bugzilla – Bug 321015
Inappropriate window given focus/raised when switching workspaces
Last modified: 2020-11-06 20:09:40 UTC
When a new window has the window manager input hint set to False, metacity (properly) does not give it focus on mapping, and sets the "demands attention" hint in the window state accordingly. However, if the window is set to appear on all workspaces, it will still be entered at the head of the "MRU" list for all workspaces; when the user switches workspaces, the window will thus be given focus (and raised), contrary to user expectations. (We have seen this inappropriate behavior with "zwgc", the Zephyr client program). I believe that this can be corrected by ignoring any window in the "demands attention" state when choosing the focus window for the activated workspace. I will provide a proposed patch soon, against version 2.12.0 (we are running version 2.8.8, but it appears that the same issue exists in the latest version).
Created attachment 54509 [details] [review] Ignore window in "demands attention" state when choosing focus window for workspace
If a normal window which demands attention is the only window in the list, it should definitely get focus (well, assuming click-to-focus or sloppy focus, or that the mouse is in the window with mouse focus). You should instead filter out windows that are input only or don't take focus. (I still don't understand the difference between window->input and window->take_focus; Havoc, could you clarify?) Also, I'm pretty certain there are other bugs about input-only windows which this might be a dupe of. Would be great if someone could check for me... :)
I thought about filtering out windows with input set FALSE, but that would lose in the case where the user had previously focused the window in the workspace. (In our case, the client sets the Input hint FALSE because it does not expect keyboard input, but it may still take focus). Focusing seems to clear the "demands attention" state, which is why I thought testing the latter was the better thing to do.
I'm guessing that you're using the globally active input model of the ICCCM, is that correct? Note that having the input field set to false, according to the ICCCM, means that the application "requests that the window manager not set the input focus to their top-level window". So, if you are expecting the window manager to give your app focus under any situation you had better not have that field set or it's your bug rather than the window manager's (at least, as far as my understanding of this part of the ICCCM goes, which is admittedly kind of shaky). AFAICT, metacity is buggy if it ever focuses such a window.
No, the application does not expect to get focus ever. But, at least in version 2.8.8, metacity WILL give it focus, and I hadn't assumed that was a bug. :) (I am also no expert on this). If metacity should indeed not give it focus, then it makes sense to test !window->input, though ideally that would be enforced consistently.
Yeah, we really need to enforce it consistently, but we really suck here and we have some more difficult problems -- even if the window doesn't accept focus, we need some way of keynaving to the window and using the Window Manager's actions (e.g. the alt-space menu) for accessibility (in other words, we can't break keynav-only environments). Other bugs on the topic: bug 154593 (especially the 13th comment), bug 155369, bug 306372, and the partially related bug 64613 (in particular the 14th additional comment). We should probably make a tracker bug for all of these...
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports in Bugzilla which have not seen updates for many years. If you can still reproduce this issue in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/metacity/-/issues/ Thank you for reporting this issue and we are sorry it could not be fixed.