From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Francis Litterio Newsgroups: gmane.emacs.bugs Subject: Bug in CVS Emacs frame positioning under X Date: Wed, 22 Mar 2006 03:33:25 +0000 (UTC) Message-ID: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1142998835 25634 80.91.229.2 (22 Mar 2006 03:40:35 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 22 Mar 2006 03:40:35 +0000 (UTC) Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Mar 22 04:40:34 2006 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FLuCx-0008Og-6x for geb-bug-gnu-emacs@m.gmane.org; Wed, 22 Mar 2006 04:40:27 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FLuD9-0005rI-8c for geb-bug-gnu-emacs@m.gmane.org; Tue, 21 Mar 2006 22:40:39 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FLuD7-0005qZ-Ah for bug-gnu-emacs@gnu.org; Tue, 21 Mar 2006 22:40:37 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FLuD6-0005qE-N0 for bug-gnu-emacs@gnu.org; Tue, 21 Mar 2006 22:40:36 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FLuD6-0005q7-IK for bug-gnu-emacs@gnu.org; Tue, 21 Mar 2006 22:40:36 -0500 Original-Received: from [80.91.229.2] (helo=ciao.gmane.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1FLuDB-0008A2-Al for bug-gnu-emacs@gnu.org; Tue, 21 Mar 2006 22:40:41 -0500 Original-Received: from root by ciao.gmane.org with local (Exim 4.43) id 1FLuCo-0008Nt-85 for bug-gnu-emacs@gnu.org; Wed, 22 Mar 2006 04:40:18 +0100 Original-Received: from ppp0a032.std.com ([69.38.146.32]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 22 Mar 2006 04:40:18 +0100 Original-Received: from flitterio by ppp0a032.std.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 22 Mar 2006 04:40:18 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-To: bug-gnu-emacs@gnu.org Original-Lines: 54 Original-X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: main.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 69.38.146.32 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7) X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:14980 Archived-At: In the latest CVS Emacs under X, there seems to be a frame positioning bug that is timing related. It doesn't happen deterministically, and I'm still trying to create a test case that reproduces the problem. However, I added some printf()s to the code in src/xterm.c, and I've seen the following things happen in this order: 0. Assume a frame is positioned at x/y location 50/50. 1. The user executes a command that positions the frame by doing something like this: (set-frame-position theframe 200 200) 2. In src/xterm.c, x_set_offset() is called. 3. x_set_offset() calls XMoveWindow(..., 200, 200). 4. Next, x_set_offset() sees that f->wm_type == X_WMTYPE_UNKNOWN, so it sets f->check_expected_move to 1 and stores 200 in f->expected_top and stores 200 in f->expected_left. It then returns. 5. Emacs receives a ConfigureNotify event from X, which causes handle_one_event() to be called. 6. handle_one_event() calls x_real_positions() to obtain the current real x/y location of the frame. It stores the x offset in f->left_pos and the y offset in f->top_pos. Here is the bug: In some cases, the current real x/y location of the frame is 50/50 (i.e., it appears to have not moved yet) and in some cases it is 200/200 (i.e., it appears to have moved already). 7. handle_one_event() calls x_check_expected_move(), which determines whether the window manager is type A or type B. The difference between type A and B window managers is that when positioning a frame to x/y location 0/0, type A window managers will put the window decorations at least partly off-screen, and type B window managers will not. 8. x_check_expected_move() compares f->expected_top to f->top_pos and f->expected_left to f->left_pos. When f->top_pos is 50 (which it is _some_ of the time) and f->expected_top is 200, then x_check_expected_move() sets f->wm_type to X_WMTYPE_A and sets f->move_offset_top to 150 = 200 - 50. Similarly for the From that moment on, all attempts to set the top offset of that frame causes 150 to be added to the user-supplied top offset! The same applies for the frame's left offset. When I create a reproduceable test case, I'll send it, but I'm hoping this description of the problem is enough to perhaps help someone get to the bottom of the problem. -- Francis Litterio flitterio@gmail.com