GNOME Bugzilla – Bug 524110
Gdk should not assume reparenting WMs when retrieving window frame extents
Last modified: 2009-11-25 05:15:07 UTC
Please describe the problem: Currently, Gdk assumes a reparenting window manager when retrieving window frame extents in the function gdk_window_get_frame_extents. The problem with that approach is that while reparenting is common among WMs, not every WM does that as it's not required by any spec to do so. This will cause wrong frame extents being reported under non-reparenting WMs, such as Compiz. A better solution would be using the _NET_FRAME_EXTENTS property defined by the EWMH: http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#id2512071 This would cause the frame extents being correctly reported by _any_ EWMH compliant WM, and assuming EWMH compliance should be way safer than assuming reparenting. Steps to reproduce: 1. 2. 3. Actual results: Expected results: Does this happen every time? Other information:
Created attachment 107913 [details] [review] Patch for using _NET_FRAME_EXTENTS This patch implements using _NET_FRAME_EXTENTS instead of walking up the window tree. See above for reasons. If desired, I can also create a patch that leaves the old code in for compatibility reasons.
I don't think we want to break compatibility with older window managers.
Created attachment 107983 [details] [review] Use _NET_FRAME_EXTENTS, but fall back to parent check This patch uses _NET_FRAME_EXTENTS, if available. If not, the old, parent-checking code is used as a fallback path. This patch should cause no regressions on older WMs.
Can confirm this bug... Really annoying...
The corresponding bug in openSUSE is https://bugzilla.novell.com/show_bug.cgi?id=342595
Patch looks good to me. Please commit.
2008-05-25 Cody Russell <bratsche@gnome.org> Bug 524110 - Gdk should not assume reparenting WMs when retrieving window frame extents * gdk/x11/gdkwindow-x11.c (gdk_window_get_frame_extents): Use _NET_FRAME_EXTENTS, if available. Patch by Danny Baumann.
*** Bug 536159 has been marked as a duplicate of this bug. ***
I am seeing this behavior in Ubuntu Karmic using libgtk2.0-0 2.18.3-1ubuntu2 I can see that this was fixed some time ago, so is this a regression in gtk or something specific to the Ubuntu package?