#1 oscillating window focus

[Ben Wise]

occaisonally, one can get high-frequency oscillation of
focus between windows. it can happen in normal
operations (just move the mouse and it will stop). It
can happen you kill/start the wm.

Either way, it appears to be a side-effect of
overlapping windows and raise-on-focus, but the exact
conditions remain a mystery.This is rare and I've never
been able to produce it on purpose, so there's been
little progress in debugging it. Understanding exactly
how the focus is oscillating would be a start, then
figuring out how to stop it.

[Ben Wise]

Logged In: YES
user_id=195593

I found a way to reliably induce the flicker:
First, get any empty workspace.
Use ctrl-btn-3 on the root to set 'Raise on Focus'
Create a large xterm, say 1/3 of the screen.
Create a smaller xterm, that would fit entirely inside the
large one.
Drag the little one onto the big one, and then (keeping the
mouse inside the smaller one) release.
Presto!
The flicker will indefinitely persist, as long as the mouse
stays inside the smaller xterm.

[Ben Wise]

Logged In: YES
user_id=195593

Added counting of X-events, so that the queue of X Events
must get drawn down before the auto-raise actually occurs.
The problem was that raising a client would generate
X-Events, which would sufficiently delay processing that 2
(or more) enter-window events could get into the queue.
Processing the first would add a bunch of events (including
another enter-window when this one was raised), thus always
keeping two or more enter-window events in the queue.

Waiting to raise the window until after the queue is drawn
down solves this problem.

[Ben Wise]

Logged In: YES
user_id=195593

Added counting of X-events, so that the queue of X Events
must get drawn down before the auto-raise actually occurs.
The problem was that raising a client would generate
X-Events, which would sufficiently delay processing that 2
(or more) enter-window events could get into the queue.
Processing the first would add a bunch of events (including
another enter-window when this one was raised), thus always
keeping two or more enter-window events in the queue.

Waiting to raise the window until after the queue is drawn
down solves this problem.

[Ben Wise]

Logged In: YES
user_id=195593

posted correct "Resolution" as "Fixed"