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 765100 - GDK: gdk_window_reparent does not position/size a reparented window correctly
GDK: gdk_window_reparent does not position/size a reparented window correctly
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Backend: Win32
3.0.x
Other Windows
: Normal normal
: ---
Assigned To: gtk-win32 maintainers
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2016-04-15 11:21 UTC by Jeremy Tan
Modified: 2016-04-15 13:30 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Sample program that exhibits issue (2.28 KB, text/plain)
2016-04-15 11:21 UTC, Jeremy Tan
  Details
Proposed patch to fix issue (1.34 KB, patch)
2016-04-15 11:26 UTC, Jeremy Tan
committed Details | Review

Description Jeremy Tan 2016-04-15 11:21:50 UTC
Created attachment 326086 [details]
Sample program that exhibits issue

As specified in the documentation, gdk_window_reparent must reposition the child window with respect to its parent window.

However, the current implementation does not achieve this in certain cases. For example, if Window C is reparented to Window B which is a child of Window A (toplevel), Window C will actually be positioned with respect to Window A.

This is displayed in the attached sample code. Using the current implementation, the green coloured window is incorrectly positioned in the upper-left hand corner of the toplevel window. It should actually be positioned with respect to the red coloured window.

The reason for this is that gdk_window_reparent calls MoveWindow to perform the move. This is in contrast to all other move/resize functions within GDK W32, which uses SetWindowPos.

Another effect of using MoveWindow is that if a window is reparented to be toplevel, it will be sized without accounting for the size of window decorations. This will result in the client area being smaller than expected.

The expected behaviour as described has been confirmed to work under Linux(X11).

A reasonable fix would be to remove the call to MoveWindow and to replace it with a call to one of the pre-existing move/resize functions, which take all of this into account, and furthermore repositions the window with respect to the parent correctly.
Comment 1 Jeremy Tan 2016-04-15 11:26:26 UTC
Created attachment 326087 [details] [review]
Proposed patch to fix issue

There are quite a few move/resize functions in gdkwindow-win32.c - I think this is the right one.
Comment 2 LRN 2016-04-15 13:28:14 UTC
Review of attachment 326087 [details] [review]:

Patch does not seem to be incorrect and does fix the bug that the testcase in attachment 326086 [details] exposes.

There's one style-related nitpick, but i'll fix that myself, since i'll have to do the pushing anyway.
Comment 3 LRN 2016-04-15 13:30:42 UTC
Attachment 326087 [details] pushed (after a minor fix) as commit 	8ebb6969cbe49e75df37d8d7b55ae0814d7f3878.