GNOME Bugzilla – Bug 140977
123123-style window activation when showing three GTK windows at the same time
Last modified: 2020-11-06 20:09:26 UTC
When showing two or more GTK windows at the same time from the same program, some windows may be activated more than once. This is a race condition that depends on system load -- the more loaded the system, the more likely activation will be repeated. I'll attach a test case that demonstrates the problem. I tested it against current GTK and metacity HEAD. This behaviour presents problems for libgcj's AWT implementation, since AWT programs only expect one WINDOW_ACTIVATED event when a window is activated. The problem seems to stem from metacity's meta_window_focus. There, focus is given to the target window twice: once directly via XSetInputFocus and once indirectly by sending a WM_TAKE_FOCUS icccm message to GTK (which calls _gdk_x11_set_input_focus_safe in response). GTK interprets the WM_TAKE_FOCUS message from the window manager to mean "if you want, you may now give the focus to one of your sub-windows instead of the top-level". In most cases, GTK will transfer focus to one of its sub-windows which causes another focus-in event to be delivered. The reverse happens when focus is transferred to another top-level, so two sets of focus-in/focus-out events are delivered to each window when multiple windows are shown. Havoc thought that this may have been reported before, but I couldn't find an existing bugzilla entry, so I'm filing this.
Created attachment 27031 [details] GTK test case that demonstrates 123123-style window activation
Would it be possible to add an "if (window->has_focus) return;" to the beginning of meta_window_focus? Here are some other cases where a window can be focused more than once (I'm pretty sure there are others I forgot; it wasn't until a few days ago that I decided to write all these down): meta_screen_show_desktop's call to meta_workspace_focus_top_window results in the same window being focused again (see bug 151990) the one-line bugfix for 124798 would introduce a double-focus case under most circumstances (I have two slightly different bugfixes in mind for that case, one of which would introduce the same double-focus case, the other of which wouldn't) apparently, every window gets two EnterNotify events when the mouse enters them, resulting in a double focus whenever using sloppy or mouse focus before the patch in bug 131582 was applied there was a triple focus case whenever the mouse window was the same as the mru window, sloppy or mouse focus was in use, and the user closed or minimized a window. (we will again have this once the patch in bug 152000 is applied, but it won't depend on what the mru window is, just whether there's another window under the mouse)
> Would it be possible to add an "if (window->has_focus) return;" to the beginning > of meta_window_focus? This creates a race, because we may think a window is focused but it may no longer be focused. We want the last window meta_window_focus() is called on to "win", so window->has_focus is the wrong way to see if the current window we're focusing is the same as the one we just focused. window->has_focus reflects the last focus event we got, not the last focus request we sent. I think display->expected_focus_window may be what we want to check here? I don't remember the details of that field but maybe it's the last focus request we sent. I don't think avoiding double-focus fixes this bug though; isn't this bug simply caused by sending both SetInputFocus and the WM_TAKE_FOCUS client message... reading the ICCCM it's a bit unclear that doing both is right for locally active clients, but it seems logical to do both. cc'ing Owen since he probably already knows about this issue.
See also bug 154598.
Moving things to focus component. Sorry for spam.
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.