Re: Confirming this bug still exists.

[GSR - FR <famrom infernal-iceberg com>]

Hi,
dan merillat gmail com (2008-01-15 at 1735.31 -0500):
> A similar problem happens with firefox/mozilla suite URL completion -
> if I type quickly, focus bounces around and characters drop.  Having
> to slow my typing down to a hunt-and-peck speed is extremely
> obnoxious.

I use "enter only", no difference if the mouse is over the place the
popup takes, or far away. My grumble with that popup has always been
that that I can type faster than the app reacts, so I hit some keys
followed by Tab (all in one go, because I know that key sequence is
unique), and instead of completing, it just moves the focus around the
browser, never mind it tends to be distracting in general (one reason
I dislike the "always or never suggest, choose in Prefs" mode instead
"complete upon request, stay quiet otherwise" like in shells). I take
modern interfaces are for hunt and peck, anything else is too fast
"for the computer".

OTOH I have an issues with focus jumping that matches more your
description, when the window is shaded and I focus it with shade hover
focus feature on, popups or menus open and, at the same time, the
parent window is hidden but showing focus state (based in title bar
decor type).

In FF the first menu does not trigger the shadding, the next one does
(click File, then drag to Edit), while plain GTK apps do it for the
first children. QT apps go farther, shade and unfocus (again based in
title bar decor). It is a nasty behaviour and no idea why each behaves
differently (I thought FF used GTK for handling windows... I guess not
100% same way). There is a patch about QT/KDE menus in wiki, but then
QT apps started doing something else. Big quiz.

How do you plan to inspect the events?

GSR