Standardizing ConfigureRequest vs. size_inc hints

[Dominik Vogt <dominik vogt fvwm org>]

There has long been a race condition between COnfigureRequest
events and changing the width_ind/height_inc members of the normal
wm hints:

--

Let's assume we have a 100x100 client window with width_inc =
height_inc = 10.  Consider this scenario.

 1) Window changes the ..._inc to 5.
    [WM should resize window to 50x50]
 2) Window resizes its window to 100x100
    [New required size: 100x100]
 3) Window changes the ..._inc to 20.
    [New requiredd size: 400x400]

Let's furter assume that the client sends all these requests in
one batch.  There are some applications that actually do this.
Now the problem is that XSetWMNormalHints() sets the wm hints
property on the window and then sends a PropertyNotify to the WM.
The real flow of events and actions is this:

 1) Window changes the ..._inc to 5.
 2) Window resizes its window to 100x100.
 3) Window changes the ..._inc to 20.
 4) The X server processes the first request, sets the ..._inc to
    5 and sends a PropertyNotify to the WM.
 5) The X server forwards the ConfigureRequest to the WM.
 6) The X server processes the last request, sets the ..._inc to
    20 and sends a PropertyNotify to the WM.
 7) The WM takes the PropertyNotify off the input queue.  Since
    the wm normal hints have changes, it reads the corresponding
    property from the window.  The ..._inc value is 20, so the
    window is resized to 200x200.
 8) The WM gets the ConfigureRequest and resizes the window to
    100x100.
 9) The WM gets the second PropertyNotify, reads the hints again
    and changes nothing because the ..._inc is still 20.

==> Final window geometry: 100x100 while the client wanted
    400x400.

If you want to see this bug in effect for yourself, fire up an
xterm with

  $ xterm -g 80x24+0+0

Give it the focus and then hold down ctrl-shift.  With these
keys held, hammer on the KP_plus and KP_minus keys as fast as
you can for a couple of second.  When you're done, richt click the
xterm window and switch back to the medium font size.  More often
than not, the xterm geometry is totally screwed up.

Any window manager that handles changes of the ..._inc hints
should suffice to surface the problem.

--

The problem is that the new size caused by changing the ..._inc is
not communicated by an event but must be polled by the WM.  There
are several ways to prevent this race condition:

 * Require the app to wait for a matching ConfigureNotify each
   time it sets the normal wm hints.  This may not fit well with
   the design of some applications.  Also, it's impossible to
   determine if that a particular ConfigureNotify event was caused
   by XSetWMNormalHints() or not.

 * Upon receiving the PropertyNotify, the WM reads the ..._inc
   hints and responds with a client message.  The client is not
   allowed to change that property again before it received the
   client message.  This too is problematic because it forces the
   client to wait for a response.

 * The client calls XSetWMNormalHints() as usual and follows it
   immidiately with a client message to the root window that
   contains the requesting window id and the new ..._inc values
   as well as the new base_width and base_height.  The WM ignores
   the PropertyNotify completely and takes the values from the
   client message instead.  The disadvantage is that two requests
   are sent to the X server, but the application doesn't have to
   wait for a reply.  Furthermore it can treat a compliant window
   manager exactly the same as a non compliant one.  Only the
   window manager needs to know if the application is compliant
   (use client message) or not (use PropertyNotify).

A NET WM compliant window manager is *required* to handle that
protocol when it detects a NET WM compliant application.  And a
compliant application is *required* to partake in this protocol
when it detects a compliant WM.

--

Personally I'd prefer the third solution because it can be
implemented with minimal changes in the application and the
window manager and has the least side effects.

I think it's a good idea to pout some rules into the spec so that
at least new applications don't run into this problem anymore.

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, dominik vogt gmx de
Reply-To: dominik vogt gmx de