After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 140977 - 123123-style window activation when showing three GTK windows at the same time
123123-style window activation when showing three GTK windows at the same time
Status: RESOLVED OBSOLETE
Product: metacity
Classification: Other
Component: Focus
2.8.x
Other Linux
: Normal normal
: ---
Assigned To: Metacity maintainers list
Metacity maintainers list
Depends on:
Blocks: 155450
 
 
Reported: 2004-04-23 21:08 UTC by Thomas Fitzsimmons
Modified: 2020-11-06 20:09 UTC
See Also:
GNOME target: ---
GNOME version: 2.9/2.10


Attachments
GTK test case that demonstrates 123123-style window activation (4.39 KB, text/plain)
2004-04-23 21:11 UTC, Thomas Fitzsimmons
Details

Description Thomas Fitzsimmons 2004-04-23 21:08:59 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.
Comment 1 Thomas Fitzsimmons 2004-04-23 21:11:11 UTC
Created attachment 27031 [details]
GTK test case that demonstrates 123123-style window activation
Comment 2 Elijah Newren 2004-09-07 23:00:53 UTC
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)
Comment 3 Havoc Pennington 2004-09-08 00:09:00 UTC
> 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.
Comment 4 Elijah Newren 2004-10-06 17:09:12 UTC
See also bug 154598.
Comment 5 Thomas Thurman 2008-04-20 20:19:40 UTC
Moving things to focus component.  Sorry for spam.
Comment 6 André Klapper 2020-11-06 20:09:26 UTC
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.