GNOME Bugzilla – Bug 154593
Unfocusable windows are included in the focus list
Last modified: 2020-11-06 20:07:22 UTC
Unfocusable windows (eg. gtk_window_set_accept_focus(window, FALSE)) are included in the focus list, so they are not skipped when cycling through the list with the keyboard.
Appears to be controlled by these lines in window.h: #define META_WINDOW_IN_NORMAL_TAB_CHAIN(w) \ (((w)->input || (w)->take_focus) && META_WINDOW_IN_NORMAL_TAB_CHAIN_TYPE (w)) Note that gtk_window_set_accept_focus sets the wm_hints.input field according to this line in update_wm_hints from gdkwindow-x11.c: wm_hints.input = private->accept_focus ? True : False; So, I'm guessing that for the window that gets included in the tab list that you don't want there, that window->input is false but window->take_focus is true. To verify, can you run xprop | grep -A 1 "\(WM_HINTS\|WM_PROTOCOLS\)" from a terminal and click on the app that is erroneously focused? Then just put the output here. Thanks.
WM_HINTS(WM_HINTS): Client accepts input or input focus: False -- _MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x2, 0x280c1300, 0x2, 0x81bb500, 0xe2 WM_CLIENT_LEADER(WINDOW): window id # 0x3400001 -- WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING WM_CLASS(STRING) = "mail-notification", "Mail-notification"
Yep, that looks like it confirms my guess. I believe this means one of the following: (a) it isn't a bug for this to happen, but gtk+ needs to provide a function to remove WM_TAKE_FOCUS from the list of supported protocols, (b) it's a gtk+ bug becuase gtk_window_set_accept_focus should remove WM_TAKE_FOCUS from the list of protocols as well, or (c) we need to modify that line in metacity to have either "(w)->input && (w)->take_focus" or just "(w)->input". Havoc, Rob: What's the correct thing here?
Um... I have a feeling there's info about gtk_window_set_accept_focus() and its genesis that I should remember, but I don't. I think we have to ask the gtk guys.
Ok, I'm cc'ing gtk-bugs to ask them what the right thing to do is here.
The relevant bug to study is bug 64613
OK, I think the answer is that the client (whether GTK or the app code) needs to set SKIP_TASKBAR/SKIP_PAGER in this case. We can't tell the window is unfocusable, since it has WM_TAKE_FOCUS.
Sorry for jumping in this discussion, but isn't the idea that even unfocussable windows should be in the Alt-Tab list, in order to allow keynav access to the wm menu ?
Right, I forgot about that. The other option is the Ctrl+Alt+Tab list (with panels and desktop). I think we put skip_tasklist/pager stuff in there too, or were at least thinking about it.
Sounds like the right idea to me.
Unfocusable windows should not be in the Alt-Tab list. Releasing Alt while they are hilighted will not focus them anyway (but that might give the currently focused window a non-focused aspect, causing some confusion).
I didn't state that they should be in the alt tab list; my summary said that they should be in the ctrl-alt-tab list.
There is a separate issue that if an app is advertising WM_TAKE_FOCUS but not accepting focus, you can't keynav that app even with ctrl+alt+tab. I think there may be a bug on that; there was some thought a while back about having a concept of "focusing" an app without it having the X focus.
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.