From unknown Sun Jun 22 00:57:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#62135: xterm.c: (x_set_offset) Resent-From: Madhu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 12 Mar 2023 01:32:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 62135 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 62135@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.167858467225452 (code B ref -1); Sun, 12 Mar 2023 01:32:02 +0000 Received: (at submit) by debbugs.gnu.org; 12 Mar 2023 01:31:12 +0000 Received: from localhost ([127.0.0.1]:58849 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pbAYJ-0006cS-VQ for submit@debbugs.gnu.org; Sat, 11 Mar 2023 20:31:12 -0500 Received: from lists.gnu.org ([209.51.188.17]:40266) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pbAYH-0006cJ-Kz for submit@debbugs.gnu.org; Sat, 11 Mar 2023 20:31:10 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pbAYH-0003l8-9P for bug-gnu-emacs@gnu.org; Sat, 11 Mar 2023 20:31:09 -0500 Received: from smtp5.ctinetworks.com ([205.166.61.198]) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pbAYE-0005AC-4Y for bug-gnu-emacs@gnu.org; Sat, 11 Mar 2023 20:31:08 -0500 Received: from localhost (unknown [117.193.7.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: enometh@meer.net) by smtp5.ctinetworks.com (Postfix) with ESMTPSA id 99213165CAC for ; Sat, 11 Mar 2023 20:29:55 -0500 (EST) Date: Sun, 12 Mar 2023 06:58:43 +0530 (IST) Message-Id: <20230312.065843.1304315041062918300.enometh@meer.net> From: Madhu X-Mailer: Mew version 6.8 on Emacs 30.0.50 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ctinetworks-Information: Please contact the ISP for more information X-ctinetworks-MailScanner-ID: 99213165CAC.A6561 X-ctinetworks-VirusCheck: Found to be clean X-ctinetworks-SpamCheck: X-ctinetworks-Watermark: 1679448597.10667@ch12PxrSboFadcdxJcL8Lg Received-SPF: pass client-ip=205.166.61.198; envelope-from=enometh@meer.net; helo=smtp5.ctinetworks.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.4 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) 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. 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. I hope martin can pick this up from here and take a look? ---Regards, Madhu ``` 22663 /* CHANGE_GRAVITY is 1 when calling from Fset_frame_position, 22664 to really change the position, and 0 when calling from 22665 x_make_frame_visible (in that case, XOFF and YOFF are the current 22666 position values). It is -1 when calling from gui_set_frame_parameters, 22667 which means, do adjust for borders but don't change the gravity. */ 22668 static void 22669 x_set_offset (struct frame *f, int xoff, int yoff, int change_gravity) 22670 { 22671 int modified_top, modified_left; 22672 #ifdef USE_GTK 22673 int scale = xg_get_scale (f); 22674 #endif 22675 if (change_gravity > 0) 22676 { [...] 22689 #ifdef USE_GTK 22690 if (x_gtk_use_window_move) 22691 { 22692 /* When a position change was requested and the outer GTK widget 22693 has been realized already, leave it to gtk_window_move to 22694 DTRT and return. Used for Bug#25851 and Bug#25943. Convert 22695 from X pixels to GTK scaled pixels. */ 22696 if (change_gravity != 0 && FRAME_GTK_OUTER_WIDGET (f)) 22697 gtk_window_move (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)), 22698 f->left_pos / scale, f->top_pos / scale); 22699 unblock_input (); 22700 return; 22701 } 22702 #endif /* USE_GTK */ 22703 modified_left = f->left_pos; 22704 modified_top = f->top_pos; 22705 if (change_gravity != 0 && FRAME_DISPLAY_INFO (f)->wm_type == X_WMTYPE_A) 22706 { 22707 /* Some WMs (twm, wmaker at least) has an offset that is smaller 22708 than the WM decorations. So we use the calculated offset instead 22709 of the WM decoration sizes here (x/y_pixels_outer_diff). */ 22710 modified_left += FRAME_X_OUTPUT (f)->move_offset_left; 22711 modified_top += FRAME_X_OUTPUT (f)->move_offset_top; 22712 } 22713 #ifdef USE_GTK 22714 /* Make sure we adjust for possible scaling. */ 22715 gtk_window_move (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)), 22716 modified_left / scale, modified_top / scale); 22717 #else 22718 XMoveWindow (FRAME_X_DISPLAY (f), FRAME_OUTER_WINDOW (f), 22719 modified_left, modified_top); 22720 #endif ``` In GNU Emacs 30.0.50 (build 2, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw3d scroll bars) of 2023-02-14 Configured using: 'configure --with-x-toolkit=athena --with-native-compilation -C' From unknown Sun Jun 22 00:57:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#62135: xterm.c: (x_set_offset) Resent-From: Po Lu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 12 Mar 2023 09:19:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62135 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Madhu Cc: 62135@debbugs.gnu.org Received: via spool by 62135-submit@debbugs.gnu.org id=B62135.167861273917286 (code B ref 62135); Sun, 12 Mar 2023 09:19:02 +0000 Received: (at 62135) by debbugs.gnu.org; 12 Mar 2023 09:18:59 +0000 Received: from localhost ([127.0.0.1]:59168 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pbHr1-0004Uj-7P for submit@debbugs.gnu.org; Sun, 12 Mar 2023 05:18:59 -0400 Received: from sonic301-31.consmr.mail.ne1.yahoo.com ([66.163.184.200]:34229) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pbHqz-0004UO-82 for 62135@debbugs.gnu.org; Sun, 12 Mar 2023 05:18:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1678612729; bh=lPftVYhkihbbb4uKnAp/Q9tY3QnG4iVrnKhQQh/DMKs=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=DeJDdypsHXdJtvZ9kkw3FWyP68YgYT1UlLn8dtKTyZRkKXBPqJtM1KdpHAJk+g/lGAQzdty3kZYwTNDyK3J5+gmS3oY5iIcPhEUnQXNZ5xmVsNvnW5uQxRo2LqCoPmW8c0X2Nue+Le1HhUgs1AncSxE6/IWuSazOzCnIb3iChTzR6Yxwj9KKL2DeUbXtxktlB9034rT6vPB44PyGMWb9/74aPo4fsijpMnqX42LyXF3KWqunoTgaVLqFyFnobsuvvfdeYC5IEl+0OWmDAf4W9Dkx8fhrtTk7ANMyeaGg1Zc4ulpbcf3v45JFRe8FyzF4HUCAi0QvFY3knUNacLXBQA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1678612729; bh=EoPy2udH4nRtM/wshlzP3bAmMR6FG070YJgPdln0BEC=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=EB7e7q7ZnqU+Iu2o9GX4RSEz9H+KjxWrcHaRjVozmtLd7LswQ3lEWdaslOsCeWiQ5oI3HKEmt8pkZ4niS/sEuHwfBlOx6WVlfS3Y8lynP10Me6Pc1cxAbhkyeSnR6VZBx73g1NaTYRCOZ7och1pTnK1qyF5yYpuBRdUksceDsasfuE6Pnu1zTCvlpOP5MaE1yIiRqbA34w5sZtN12U4ojEgFS1ANLYTSFuoM6VM2t4bXDRbRgIXJgca6krMvPzFlTf0TlwECFljLjTyytw16xQ4uIZMok+WMw2Q2T1mt0SQKj/Duu765FvhyrJ7jchm6yJFVfKfFciwf7fz0zaG8sA== X-YMail-OSG: aKm1NRQVM1kw89.s12z6D8fHfvy6Jq7XvqQBboD7ixtRHTsqEZYhgdsc3fXd8KF kaa.KngffAca7yxymqij1Y2daFl58L642k3Qi7m_oBo9AOqAb4pNOK0CxiAta9fGqdew1hl8fG5T qp3hJ_IyxPq6ffyMZgLBy4AV30L4vnRQKMwtKW9v19_D5P5NPYc6653CJqCye8PCKSSEjCnhFGkh YIfuh1F9GWkMqr4zFA9XIpfq8I284WmZYrXXG_d11dAbdr3FiREqm2MJLz7GmFjPJ8hd9QraynJi 8FxQt00a4gwWk9uKEYK36sHeoO_7Ng352qrtG5ZfGU.nOoSM5nMmtTt6cLqT542883Ojh1MxSqjP 43eZFjJGUS1UNmjCjzzyYN2mAAYnXyHo96xk2sft6FF1DOqcQaKtgcILCr3WLY6CgyylqbrmYCyo ASbNWDDRbteB4nl3dUP9szbHNYJRHOQjjUos.xspfIv_lYhARjcd4glchlEP46C57r4HsxQ1.fAw XYMJIU8HZgVryTbJWsDoFprus.BbZbpm2snExoeWhQdpSOwyt1.tkoJPZHnARplNX7nut1ys8hFD GSjLO2yqQPmJStGNExpRPqgWIxhFCk9nkLDPOgmc.O4_BSfYXuJlXK0xoBmNScvAD87lq8.ukYkw .5cPEdjyqariLrLu0iO_qwswk099zTzy2xBrr0TTp_2w0L3TviJ.87WiUxSY5ZBEZLDMii9cV3i. CCgqqBR3oUxJOnC44rYkEa6kUXYPx7GHy5jfSBRDUFhPEWhVtYWO26JVLt43xy6bQ.vv_oxWEPSO A1IrX_K5U4ln487OCRr2.XVdun4V.RCn6OQeAy6OkqSpW0z7YMbUI3f5WYyo8xhSzJoXL9TGEKfc 8AgKDjx4FkS1wBmac_WFM5yS5MD5wbT3PLVwSpV2V0jJidyL9__QPKBvV7SX98lL9PrVNLs0oKMl 9Q.d.GYGIKBizHtA2sWQNTIDNF0Cy7V7GgNr8uOsDK0ekUH1wi5srZEOiGoLLM4idOiPxwtLvhin jIpeE2pjlLiyt61Cx0sR.FNCboZY_wUsbrJtIj2lpujjKrS.QM0Rji.Hm.EW7ZH2oO5KpdCsXtEt LbQNi6q9iutTyLr5IFsmIsqB6szFFymDf7iB4IGkL6UZ6DagKzBY6nQNQcO_wfdQE00wlcZP.yF9 x2nFLvWrPeDhQT.WAo7ImalwQ40SfWHrkxdRI2T5yolhRd_d.CyaBPISbt2fw7f62zTlpk3c5Vu5 SepsFrHz046l2RWKl_QfUlE4JbbQdWYEuBsiQ.hAdpeMT9sbYMEwxmv.1ewyhfx9qFiQ5OUWgwjU zuJEMXkPi4uzY47RRiPkBdU13nRVPaZHncWGCBJ3R3QyK8UsDna3XP9bg3doJelzbpGQVfkUhpQ1 h6HkNAwNIaIXZJq20t9mvzT8y7qiv_BA2QX5iTuz9MpZcrAGernpnexHkICkwx8xIhXxDKnY4jAo NNG7GCBRXA4Me6tTjpm2IBsYA9rP2Por3An0.l26lMJ_OluAR0RKPKvjXYmihWlWzmzYYy7Gnssk .8pWSvYS_2MYIQXE8YOgQOhS80fFSKBPzmNp2UBRDwbxuI8hgfUrxNdhaQX6Y.SnKpTjpJTA6XH. JpWFJrKD5UYFWh9tqXo.i64V3PY6Kl0OA.JzlRR0Muso4KdR87zW.Z1HWYtMwmLvT9.msTriD1sv 5Z3QupRIA19dMtEfPn0f4df4AF9cH6pBGZOHOPFemhGzev.tmnxnTvf_P_5wRuh7oNC7jI.BP3rI .g48G1Tu9esXlfKIdyzd6Eu9KEhd1VbSsjE0n1VrNtHjq44jhM_0DXBWq5pFdVFsVI84kY_1mxpL DItMtAdtLpz0rhfe4rgAELsVvWVCjH8RCQfuUogznqMUKZXIDEhn6MI3kjwhA2h4Y66VoG69o2Cc ueaKisY5PekCW2zpzg7.PwJSI_QbjIoMzeUqQedr2WgmhnukDQ360.2MBwhvKHP8fx.X5f74Zts_ 5q7qTGsrScZDMCkJtExoCMnLh19umd4MPOUIUC63JIV7VehmBq07Fj1UcI8CMB9s6IiJBqYdj3dX 19YEJix5CQFppfNcKdzWmQu7Pgb5RiCC71d7ruO_eaMj.ApDJOl4c7qCI7mLuuuzELAUIGUJlXeJ 6dQ9TooSVMm3FFzwugUMx5kpW4bKS8wk4YIv4I0IP.GRxE_bXfMyT21KPSCwo6Tz00wPpb7F5xCm tDDDCsMBuCT1JGTROHUPyvj.UcwexGcN9YItd_3DIX_dTA91lwtgfE5RZrl0q_9WC X-Sonic-MF: X-Sonic-ID: f763e68b-5c99-45b2-a612-0a544b94e228 Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.ne1.yahoo.com with HTTP; Sun, 12 Mar 2023 09:18:49 +0000 Received: by hermes--production-sg3-67c57bccff-5hdhr (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 2ef12134fdd75ca614ce5b5232596fbc; Sun, 12 Mar 2023 09:18:42 +0000 (UTC) From: Po Lu In-Reply-To: <20230312.065843.1304315041062918300.enometh@meer.net> (Madhu's message of "Sun, 12 Mar 2023 06:58:43 +0530 (IST)") References: <20230312.065843.1304315041062918300.enometh@meer.net> Date: Sun, 12 Mar 2023 17:18:35 +0800 Message-ID: <87y1o2ba50.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.21284 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 2096 X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Madhu 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. From unknown Sun Jun 22 00:57:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#62135: xterm.c: (x_set_offset) Resent-From: Madhu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 25 Mar 2023 14:22:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62135 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: luangruo@yahoo.com Cc: 62135@debbugs.gnu.org Received: via spool by 62135-submit@debbugs.gnu.org id=B62135.167975408832089 (code B ref 62135); Sat, 25 Mar 2023 14:22:01 +0000 Received: (at 62135) by debbugs.gnu.org; 25 Mar 2023 14:21:28 +0000 Received: from localhost ([127.0.0.1]:43185 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pg4ls-0008LU-BG for submit@debbugs.gnu.org; Sat, 25 Mar 2023 10:21:28 -0400 Received: from smtp5.ctinetworks.com ([205.166.61.198]:52880) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pg4lq-0008LM-Bp for 62135@debbugs.gnu.org; Sat, 25 Mar 2023 10:21:26 -0400 Received: from localhost (unknown [117.193.4.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: enometh@meer.net) by smtp5.ctinetworks.com (Postfix) with ESMTPSA id 6C9FC173648; Sat, 25 Mar 2023 10:21:22 -0400 (EDT) Date: Sat, 25 Mar 2023 19:50:34 +0530 (IST) Message-Id: <20230325.195034.1474281229503255405.enometh@meer.net> From: Madhu In-Reply-To: <87y1o2ba50.fsf@yahoo.com> References: <20230312.065843.1304315041062918300.enometh@meer.net> <87y1o2ba50.fsf@yahoo.com> X-Mailer: Mew version 6.9 on Emacs 30.0.50 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ctinetworks-Information: Please contact the ISP for more information X-ctinetworks-MailScanner-ID: 6C9FC173648.A9A3C X-ctinetworks-VirusCheck: Found to be clean X-ctinetworks-SpamCheck: X-ctinetworks-Watermark: 1680618084.76997@CP0QdHyK6AuzKhliH23Kdw X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) * Po Lu <87y1o2ba50.fsf@yahoo.com> Wrote on Sun, 12 Mar 2023 17:18:35 +0800 > `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: > - x_wm_set_size_hint (f, 0, false); > + x_wm_set_size_hint (f, 0, true); Thanks for your note (and apologies for the delay). I think all this does is push all windows to +0+0 all the time. > #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. >From what I see in wayfire's src/view/xwayland.c: (on_configure.callback) ``` if (!is_mapped()) { /* If the view is not mapped yet, let it be configured as it * wishes. We will position it properly in ::map() */ wlr_xwayland_surface_configure(xw, ev->x, ev->y, ev->width, ev->height); if ((ev->mask & XCB_CONFIG_WINDOW_X) && (ev->mask & XCB_CONFIG_WINDOW_Y)) { ``` During make_frame_visible, This gets ev->x == 0 and ev->y == 0 (presumably from the XMoveWindow in x_set_offset) and always pins the geometry of the view at +0+0 because it has got it from the client. It declines to pass the decision to the placement manager to place the window after the window is mapped, even though no geometry was supplied (say through --geometry 80x25+0+0) The x_gtk_use_window_move codepath actually does not call gtk_window_move (because of the change_gravity conditional I mention above) , and so the configure event does not specify values for x, y. and consequently wayfire does not pin x y. however gtk still maps the window at the correct (presumably based on its wm hints) when gtk_widget_show_all is called in x_make_frame_visible, so fortuitously there isn't a problem with gtk. I cant call foul on what wayfire's is doing. would you think otherwise? From unknown Sun Jun 22 00:57:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#62135: xterm.c: (x_set_offset) Resent-From: Madhu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 01 Apr 2024 12:43:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62135 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: luangruo@yahoo.com Cc: 62135@debbugs.gnu.org Received: via spool by 62135-submit@debbugs.gnu.org id=B62135.171197532515069 (code B ref 62135); Mon, 01 Apr 2024 12:43:01 +0000 Received: (at 62135) by debbugs.gnu.org; 1 Apr 2024 12:42:05 +0000 Received: from localhost ([127.0.0.1]:49798 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rrGzE-0003uy-LS for submit@debbugs.gnu.org; Mon, 01 Apr 2024 08:42:05 -0400 Received: from smtp0.ctinetworks.com ([205.166.61.207]:43838) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rrGz9-0003uQ-6j for 62135@debbugs.gnu.org; Mon, 01 Apr 2024 08:42:03 -0400 Received: from localhost (unknown [117.254.38.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: enometh@meer.net) by smtp0.ctinetworks.com (Postfix) with ESMTPSA id 0C4C7306F08A; Mon, 1 Apr 2024 08:41:43 -0400 (EDT) Date: Mon, 01 Apr 2024 18:11:46 +0530 (IST) Message-Id: <20240401.181146.1996160877381275609.enometh@meer.net> From: Madhu In-Reply-To: <20230325.195034.1474281229503255405.enometh@meer.net> References: <20230312.065843.1304315041062918300.enometh@meer.net> <87y1o2ba50.fsf@yahoo.com> <20230325.195034.1474281229503255405.enometh@meer.net> X-Mailer: Mew version 6.9 on Emacs 30.0.50 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ctinetworks-Information: Please contact the ISP for more information X-ctinetworks-MailScanner-ID: 0C4C7306F08A.A184D X-ctinetworks-VirusCheck: Found to be clean X-ctinetworks-SpamCheck: X-ctinetworks-Watermark: 1712839310.25564@ul4UeGbOM/doFSlzh9VWSw X-Spam-Score: 3.6 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: [I hope the context is available upthread on the debbugs] I took another look at the problem with wayfire: The call to XMoveWindow in x_set_offset is what's scuttling it. XMoveWindow gets called with 0, 0, wayfire thinks the window is self-positioned, and refuses to further touch the co-ordinates. Content analysis details: (3.6 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record -0.0 SPF_HELO_PASS SPF: HELO matches SPF record 3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS [117.254.38.38 listed in zen.spamhaus.org] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 2.6 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: [I hope the context is available upthread on the debbugs] I took another look at the problem with wayfire: The call to XMoveWindow in x_set_offset is what's scuttling it. XMoveWindow gets called with 0,0, wayfire thinks the window is self-positioned, and refuses to further touch the co-ordinates. Content analysis details: (2.6 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS [117.254.38.38 listed in zen.spamhaus.org] -0.0 SPF_PASS SPF: sender matches SPF record -0.0 SPF_HELO_PASS SPF: HELO matches SPF record -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager [I hope the context is available upthread on the debbugs] I took another look at the problem with wayfire: The call to XMoveWindow in x_set_offset is what's scuttling it. XMoveWindow gets called with 0,0, wayfire thinks the window is self-positioned, and refuses to further touch the co-ordinates. I think that call to XMoveWindow should be protected by a conditional: ``` if (change_gravity != 0) XMoveWindow (FRAME_X_DISPLAY (f), FRAME_OUTER_WINDOW (f), modified_left, modified_top); ``` so we avoid calling XMoveWindow even before the frame is mapped for the first time. Right? From unknown Sun Jun 22 00:57:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#62135: xterm.c: (x_set_offset) In-Reply-To: <20230312.065843.1304315041062918300.enometh@meer.net> Resent-From: Madhu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 02 Apr 2024 03:40:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62135 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 62135@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.171202919613082 (code B ref -1); Tue, 02 Apr 2024 03:40:01 +0000 Received: (at submit) by debbugs.gnu.org; 2 Apr 2024 03:39:56 +0000 Received: from localhost ([127.0.0.1]:52013 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rrV06-0003Ow-J8 for submit@debbugs.gnu.org; Mon, 01 Apr 2024 23:39:56 -0400 Received: from lists.gnu.org ([2001:470:142::17]:53458) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rrV00-0003Oa-DK for submit@debbugs.gnu.org; Mon, 01 Apr 2024 23:39:52 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rrUzr-0002oN-Bb for bug-gnu-emacs@gnu.org; Mon, 01 Apr 2024 23:39:39 -0400 Received: from ciao.gmane.io ([116.202.254.214]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rrUzp-0001qO-UP for bug-gnu-emacs@gnu.org; Mon, 01 Apr 2024 23:39:39 -0400 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1rrUzm-0008vp-EN for bug-gnu-emacs@gnu.org; Tue, 02 Apr 2024 05:39:34 +0200 X-Injected-Via-Gmane: http://gmane.org/ From: Madhu Date: Tue, 02 Apr 2024 09:08:09 +0530 Message-ID: References: <20230312.065843.1304315041062918300.enometh@meer.net> <87y1o2ba50.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain Cancel-Lock: sha1:k7IfpRyU7CCYBy8tWQQ5n6MiJ0k= Received-SPF: pass client-ip=116.202.254.214; envelope-from=geb-bug-gnu-emacs@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) * Po Lu via <87y1o2ba50.fsf@yahoo.com> : Wrote on Sun, 12 Mar 2023 17:18:35 +0800: > Madhu 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. certainly, when called from set-frame-position. > `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. certainly, when change_gravity < 0. But I don't think this statement is true when mapping an unmapped window when change_gravity == 0. does the code in x_set_offset alter top and left positions if change_gravity == 0? unless the function changes the positions a call to XMoveWindow should not be necessary. if an existing frame has been made invisible, the x and y size hints would have been set along with USPosition and the I presume the wm (minus bugs) would use them if needed when mapping the unmapped window. likewise if a new frame is being mapped with top, left, and user-position set (I haven't double-checked this again) the wm hints would be set, and an explicit move would be unnecessary when mapping the new window. In both these cases change_gravity is set to 0, and there should be no need to move the window at this step. > Thus, the code is correct. The comment above the > function is somewhat misleading but still correct.