Bug in CVS Emacs frame positioning under X

[Francis Litterio]

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