I guess this is a bug.. it's mostly harmless though

It was not harmless at all for the user who told me about this.

Right, this bug causes a lot of grief here, since it renders the 
cycle-taks feature completely useless :`-(

Is 90996 a dupe of this bug?

Also, for me it only does spasmatic repeats when the system is under a
high load.  Under normal operating conditions, my keys don't repeat
too much, but if the system is going slowly it will think that a quick
key-tap was actually a held-down key.

*** Bug 90996 has been marked as a duplicate of this bug. ***

Ok, did some more tests to nail this down:  I replaced sawfish with
metacity. The workspace switcher (which unlike sawfish pops up a
workspace list window) suffers from the same "multi-key syndrom" as
the switche from sawfish, although less freqently: I get this MKS in
about 1 out of 5 attempts (with 4 heavily loaded workspaces).

Hope this helps.

I'm willing to do more tests.  Ideas?

--nk

If it helps at all I always get all the time when I have a galeon
1.2.5 window open, xchat 1.8.9 and pan 0.13.0. I find it impossible to
switch to the pan window, it just cycles straight past.

(window manager sawfish 1.1a, debian unstable/experimental box)

i've still never seen this, I don't think sawfish is doing anything
weird here, and it sounds like it happens in metacity as well?

What in laymans terms does RESOLVED, INCOMPLETE mean. This bug is so
annoying that Ctrl+TAB is useless for me, hardly good for GNOME. There
would appear to be a bug somewhere, whether sawfish or some other
GNOME  2 library. 

I can easily do some investigation to work out where the bug is, but
some pointers as to where to look would be appreciated.

This bug also often happens to me, each time I cycle when cpu usage is
too high. It is really annoying, making such a basic feature unusable.
I must admit I don't understand the "RESOLVED" status and "low" priority.
My workaroud is to replace "windows cycling" with the "waffle"
extension, which can be found here:
http://sawfish.skylab.org/SawfishLibraryWaffle

I would also happily help investigating on this bug if some developper
have an idea of where we can start. 

-- Thomas.
(sawfish 2.0 and gnome 2.0.x on a gentoo linux box)

Either the way you as for keyboard status changed in gnome2 or this is
not a bug directly in sawfish but some
gnome-lib.
Christiano's initial port of multi-gnome-terminal to gnome2
also shows up this weird behaviour when changing tabs.
That means if I try to change a tab, it changes to up to the 4th tab
or even worse -cycles-.

Yesterday it was as bad with sawfish (high load situation again) that
it did cycle for 5 (!) minutes.

As a cause I try to omit this feature, which is rendered useless due
to this bug.

I again did further investigate the problem and now finally came up
with a solution:

Each key that is set to do key repetition will continuosly produce
keypress and keyrelease events making it hard/impossible to just catch
a single keypress.
in the case of high load, the keyboard buffer gets filled and a
massive amount of press/release events is recognized by sawfish
causing window-cyclings of even minutes (due to the high load it takes
some time to display the next window).

in our case we use <alt/meta> and <tab> to cycle windows. so what we
probably want is to disable the autorepeat of the tab key. this can be
done by the simple shell command 'xset -r 23' (where 23 is the keycode
of the tab key on my keyboard. you can find out the keycode of your
tab key by using 'xev' ).

I am now happily using sawfish again :-)))

Soeren, I'd like to find out how to fix this problem for real.  How
did you debug this?  What keyboard buffer were you looking at?

The right way to do this is to find out why that buffer was getting
filled with duplicate keypress events, and then fix that.  Thanks for
your assistance.