bug#62135: xterm.c: (x_set_offset)

[Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Madhu <enometh@meer.net> writes:

> While investingating some persistent placements at 0x0 by some wm, I was
> looking at x-set-offset, (which gets called via x_make_frame_visible).
>
> In the code below there is a comment that documents the role of the
> change_gravity argument.  When called from x_make_frame_visible the
> parameter is set to 0, so as not to do anything. However lines
> 22713-22720 perform an unconditional move window, which happens in
> this code path even before the XWindow the mapped.
>
> 1) Shouldn't these lines be protected by a "if (change_gravity != 0) {
> ... }" conditional?
>
> My surmise is that most wms ignore the call to XMoveWindow because it is
> unmapped but at least wayfire (on Xwayland) persistently seems to
> position it at 0, 0 as the code calls it.

`change_gravity' means the function should update f->top_pos and
f->left_pos, then reset the window gravity, as well as move the window
to f->top_pos and f->left_pos.

`change_gravity' < 0 means to leave f->top_pos and f->left_pos intact.

However, at that point, the window's configuration is not guaranteed to
have its origin at f->top_pos and f->left_pos, so the window must still
be moved over.  Thus, the code is correct.  The comment above the
function is somewhat misleading but still correct.

To test out one theory of mine, please say what this does:

diff --git a/src/xterm.c b/src/xterm.c
index 70bcb67d80d..de5733c8b7c 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -26956,7 +26956,7 @@ x_set_offset (struct frame *f, int xoff, int yoff, int change_gravity)
   x_calc_absolute_position (f);
 
   block_input ();
-  x_wm_set_size_hint (f, 0, false);
+  x_wm_set_size_hint (f, 0, true);
 
 #ifdef USE_GTK
   if (x_gtk_use_window_move)

> Also the 0x0 placement only happens on non-gtk builds, because I think
> there is another bug in lines 22689-22702. x_gtk_use_window_move is
> always true and gtk builds exit x_set_offset before reaching that
> line.

If that is the case, I think we have a bug in the x_gtk_use_window_move
code, and another bug (or at least misbehavior) in Wayfire.