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 150502 - _NET_WM_USER_TIME support is incomplete
_NET_WM_USER_TIME support is incomplete
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Backend: X11
2.4.x
Other Linux
: High major
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks: 149028
 
 
Reported: 2004-08-19 00:38 UTC by Elijah Newren
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: 2.8.0
GNOME version: 2.7/2.8


Attachments
Fix gtk_window_present and gdk_window_focus (1.85 KB, patch)
2004-08-19 00:50 UTC, Elijah Newren
none Details | Review
Patch to update _NET_WM_USER_TIME (2.72 KB, patch)
2004-08-20 20:55 UTC, Elijah Newren
none Details | Review

Description Elijah Newren 2004-08-19 00:38:20 UTC
gtk_window_present doesn't update the _NET_WM_USER_TIME field for the window
(unless the window is already visible), with the result that the window can
appear without focus and behind the focused window with the current metacity
behavior.

gdk_window_focus passes a _NET_ACTIVE_WINDOW message but uses the old form of
the spec for xevent data.  In particular, it neglects to pass a timestamp, which
Metacity needs.

I will attach a patch momentarily that fixes both issues.
Comment 1 Elijah Newren 2004-08-19 00:50:34 UTC
Created attachment 30730 [details] [review]
Fix gtk_window_present and gdk_window_focus
Comment 2 Elijah Newren 2004-08-19 01:04:05 UTC
Ooops, I think the xev.xclient.data.l[2] = GDK_WINDOW_XID (window); part of my
patch may be wrong.  The spec says that data.l[2] should be the "requestor's
currently active window, 0 if none", and further clarifies that "the currently
active window is the Client's active toplevel window".  I've taken a look, but
I'm not sure how to get the currently active window of an app, and I gotta run
right now.  It doesn't matter too much since Metacity ignores that field (and
libwnck recently got a patch where it's just ignored and set to 0), but I
thought I'd mention it...  and KWin might be making use of that field.

Also, this blocks bug 149028, so I'm marking it as such.  In particular, see
comment 1 and comment 46 of that bug for a case where the patch here is needed.
Comment 3 Elijah Newren 2004-08-19 18:39:29 UTC
The problems go deeper...  I'm looking into it and I'll post more later.
Comment 4 Elijah Newren 2004-08-19 21:10:54 UTC
Yeah, deeper.  I'm just going to mark as a dup of 115650 and reopen that one,
because I think it's just the case that the patch in 115650 was incomplete.

*** This bug has been marked as a duplicate of 115650 ***
Comment 5 Elijah Newren 2004-08-20 20:54:02 UTC
As per Owen's request, I'm reopening.  Let me paste the relevant comments about
the patch I'll attach in a minute:

If a user is using an app and:
  1) The app opens another window (e.g. preferences or a confirmation dialog)
  2) The app closes the window (user is done using it or whatever)
  3) The user interacts with other window
  4) The app reopens that extra window (e.g. user wants to modify more
     preferences or whatever)
then the second time the window is reopened it will appear without focus and
behind whatever window currently has focus.  This is because the
_NET_WM_USER_TIME property for that window is that stale value from previous
usage, instead of the timestamp that caused the window to be mapped as it should be.

The patch I will attach momentarily fixes this by updating _NET_WM_USER_TIME
/when necessary/ in show_window_internal.  There are two times when it isn't
necessary:
  1) When the app has already manually set it's value to 0 to request
     no focus
  2) When the app has set _NET_WM_USER_TIME to something more recent than
     the most recent user interaction with the app. (see bug 150271 for
     a case where this occurs; basically whenever we have a inter-process
     communication this can happen)
Comment 6 Elijah Newren 2004-08-20 20:55:19 UTC
Created attachment 30792 [details] [review]
Patch to update _NET_WM_USER_TIME

This patch is against the gtk-2-4 branch, although it applies easily to HEAD. 
Both need to be fixed.
Comment 7 Matthias Clasen 2004-08-23 17:11:22 UTC
Committed with some modifications.

2004-08-23  Matthias Clasen  <mclasen@redhat.com>

	* gdk/x11/gdkwindow-x11.h (struct _GdkToplevelX11): Add a 
	user_time field.

	* gdk/x11/gdkwindow-x11.c (gdk_x11_window_set_user_time): Update
	toplevel->user_time.
	(show_window_internal): Update the user time when re-mapping a
	toplevel window.  (#150502, Elijah Newren)

Comment 8 Matthias Clasen 2004-08-23 17:12:55 UTC
Committed with some modifications.

2004-08-23  Matthias Clasen  <mclasen@redhat.com>

	* gdk/x11/gdkwindow-x11.h (struct _GdkToplevelX11): Add a 
	user_time field.

	* gdk/x11/gdkwindow-x11.c (gdk_x11_window_set_user_time): Update
	toplevel->user_time.
	(show_window_internal): Update the user time when re-mapping a
	toplevel window.  (#150502, Elijah Newren)

Comment 9 Elijah Newren 2004-08-23 18:54:39 UTC
The modifications break the building of gtk+, but it's a simple one-line patch
to fix:

diff -p -u -r1.205.2.5 gdkwindow-x11.c
--- gdk/x11/gdkwindow-x11.c     23 Aug 2004 16:57:45 -0000      1.205.2.5
+++ gdk/x11/gdkwindow-x11.c     23 Aug 2004 18:53:51 -0000
@@ -1221,7 +1221,7 @@ show_window_internal (GdkWindow *window,

       g_assert (GDK_WINDOW_IS_MAPPED (window));

-      if (GDK_WINDOW_IS_TOPLEVEL (window))
+      if (WINDOW_IS_TOPLEVEL (window))
        {
          display_x11 = GDK_DISPLAY_X11 (gdk_drawable_get_display (window));
          toplevel = _gdk_x11_window_get_toplevel (window);
Comment 10 Matthias Clasen 2004-08-23 19:06:56 UTC
Thanks, fixed.