[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Bug in CVS Emacs frame positioning under X

From: Francis Litterio
Subject: Bug in CVS Emacs frame positioning under X
Date: Wed, 22 Mar 2006 03:33:25 +0000 (UTC)
User-agent: Loom/3.14 (http://gmane.org/)

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

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

        (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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]