Bug in CVS Emacs frame positioning under X

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

Re: Bug in CVS Emacs frame positioning under X

[Fran Litterio]

On 3/22/06, I (Fran Litterio) wrote:
> On 3/22/06, Richard Stallman wrote:
> >     In the latest CVS Emacs under X, there seems to be a frame positioning bug that
> >     is timing related.
> >
> > Does it happen in older CVS versions too?  For instance,
> > did it happen a month ago?  6 months ago?
>
> Unknown.  I'll check-out the older sources and rebuild.  I'll let you know.

I have checked out the CVS Emacs source code from October 1, 2005, and
the bug existed at that time.  Additionally, I have found a simple way
to reproduce the problem:

1. Start Emacs under the X Window system using the command: emacs -q

2. Evaluate the following Elisp:

	(dolist (i '(1 2 3 4 5 6))
	  (let ((frame (make-frame '((top . 50) (left . 50)))))
	    (set-frame-position frame 200 200)
	    (set-frame-position frame 300 300)
	    (sit-for 0.5)))

You may have to evaluate the above Elisp more than once to see the
malfunction (although I see it every time).

The symptom is that not all of the frames end up positioned at x/y
coordinates 300/300.  Some frames are positioned at 300+A/300+B, where
A is the width of the left border drawn by the window manager and B is
the height of the top border drawn by the window manager.  Some frames
even end up at 400/400 !

I think I have a patch to src/xterm.c that may fix this.  I will try
it and let you know if the patch works.
--
Fran Litterio

Re: Bug in CVS Emacs frame positioning under X

[Richard Stallman]

    The symptom is that not all of the frames end up positioned at x/y
    coordinates 300/300.  Some frames are positioned at 300+A/300+B, where
    A is the width of the left border drawn by the window manager and B is
    the height of the top border drawn by the window manager.  Some frames
    even end up at 400/400 !

    I think I have a patch to src/xterm.c that may fix this.  I will try
    it and let you know if the patch works.

This resembles a problem that I struggled with about 10 years ago.
It might be the same one.

I found that various cases of window positioning were a little bit
off.  So I would fix the case that failed, and then some other case
started to fail.  Eventually I gave up.

With better records, perhaps I could have determined the pattern of
what failed and what succeeded, and figured out an overall solution.
We should start keeping such records now, in case the patch
which fixes this case breaks another case.

Re: Bug in CVS Emacs frame positioning under X

[Jan Djärv]

Richard Stallman wrote:
>     The symptom is that not all of the frames end up positioned at x/y
>     coordinates 300/300.  Some frames are positioned at 300+A/300+B, where
>     A is the width of the left border drawn by the window manager and B is
>     the height of the top border drawn by the window manager.  Some frames
>     even end up at 400/400 !
> 
>     I think I have a patch to src/xterm.c that may fix this.  I will try
>     it and let you know if the patch works.

Please also tell which window managers you tested it on.

> 
> This resembles a problem that I struggled with about 10 years ago.
> It might be the same one.
> 
> I found that various cases of window positioning were a little bit
> off.  So I would fix the case that failed, and then some other case
> started to fail.  Eventually I gave up.

That is the basic problem.  Each window manager does window moves differently, 
and the fact that events may come at different times complicates things.  I 
now try to make it work on a lot of window managers, but I gave up on "all".

> 
> With better records, perhaps I could have determined the pattern of
> what failed and what succeeded, and figured out an overall solution.
> We should start keeping such records now, in case the patch
> which fixes this case breaks another case.


The patch must be tested on at least 10 or so of the most common window 
managers.  Usually it is difficult to make a patch that doesn't break some 
other window manager.

	Jan D.

Re: Bug in CVS Emacs frame positioning under X

[Fran Litterio]

On 3/25/06, Richard Stallman wrote:

>     The symptom is that not all of the frames end up positioned at x/y
>     coordinates 300/300.  Some frames are positioned at 300+A/300+B, where
>     A is the width of the left border drawn by the window manager and B is
>     the height of the top border drawn by the window manager.  Some frames
>     even end up at 400/400 !

> This resembles a problem that I struggled with about 10 years ago.
> It might be the same one.
>
> I found that various cases of window positioning were a little bit
> off.  So I would fix the case that failed, and then some other case
> started to fail.  Eventually I gave up.

My major concern is that the current malfunction has non-deterministic
user-visible effects.  Depending of the X event timing, programmatically
positioned frames can end up in one of three places:

	1. The correct position.

	2. Nearby the correct position (i.e., off by the width and height of the
           window manager decorations).

	3. Very far away from the correct position (i.e., off by hundreds of
           pixels in both the X and Y coordinates).

In cases #2 and #3, the difference between the incorrect position and the
correct position is remembered by the frame and affects all future positioning
of that frame.  In case #3, this can position a frame off-screen even if the
user specifies coordinates that are on-screen!

> With better records, perhaps I could have determined the pattern of
> what failed and what succeeded, and figured out an overall solution.
> We should start keeping such records now, in case the patch
> which fixes this case breaks another case.

The current algorithm in src/xterm.c is close to providing a universal solution,
but it makes one incorrect assumption: that the location of a frame after
calling XMoveWindow() is correctly specified in the first ConfigureNotify event
received after the call to XMoveWindow().  Function x_check_expected_move() uses
the location from the ConfigureNotify event to compensate for frames that are
mispositioned by "type A" window managers.

If there were a function that can be called to synchronously obtain the current
position of a window, then x_check_expected_move() could use that function
instead of relying on possibly incorrect data from the last ConfigureNotify
event.

I don't (yet) know enough about X Window system programming to know if such a
function exists.  If someone does know, please inform me.  If I find a solution,
I'll submit a patch.
--
Francis Litterio
flitterio@gmail.com
http://world.std.com/~franl/
GPG and PGP public keys available on keyservers.

Re: Bug in CVS Emacs frame positioning under X

[Jan Djärv]

Fran Litterio wrote:

> 
> If there were a function that can be called to synchronously obtain the current
> position of a window, then x_check_expected_move() could use that function
> instead of relying on possibly incorrect data from the last ConfigureNotify
> event.
> 
> I don't (yet) know enough about X Window system programming to know if such a
> function exists.  If someone does know, please inform me.  If I find a solution,
> I'll submit a patch.


XSync, XMoveWindow, and then XSync again should make the next ConfigureWindow 
contain the position after move.  XGetGeometry and XGetWindowAttributes should 
do the trick.

	Jan D.

Re: Bug in CVS Emacs frame positioning under X

[Richard Stallman]

    My major concern is that the current malfunction has non-deterministic
    user-visible effects.  Depending of the X event timing, programmatically
    positioned frames can end up in one of three places:

It could be that we could solve this by completely reorganizing the
way that code works.  The person who wrote it was not the best
programmer, and I then tried to fix it up with just a partial
understanding of how to use Xt.  Someone who really knows the right
way to use Xt could perhaps do this right, and then it would work.

Let's continue this discussion just on emacs-devel.