GNOME Bugzilla – Bug 145387
Losing focus while using GtkEntryCompletion
Last modified: 2004-12-22 21:47:04 UTC
When the popup created by GtkEntryCompletion is closed (because all text in the GtkEntry has been deleted) the focus is given to the window below the mouse pointer, which is not necessarily the window containing the GtkEntry. I'm using metacity with sloppy focus setting.
Is this the case of +--------------------------------+ | +-------------------------+ | | | | | | +-------------------------+ | +-| |----+ | | | X | +-------------------------+ Were the mouse point is X? This is a really nasty bug with sloppy focus that really has nothing to do with GTK+ or this widget. You can also get it to occur with menus, but menus don't usually go outside their containing toplevel. There may be a metacity bug to dup on.
Your case causes the problem, too, but actually I'm having problems with this: +--------------------------------+ | +-------------------------+ | | | | | | +-------------------------+ | +-| |----+ | | | | X +-------------------------+ The window containing the GtkEntry was focused by keyboard (or because it was just opened), and the mouse pointer is still above another window. In this case I can make the window lose focus just by entering some text (making the popup appear) and erasing it (making the popup disappear and the window loses focus). I took a look at the open metacity bugs and couldn't find anything describing anything similar, although there are quite some focus-related bugs. But perhaps I just don't understand the problem well enough to recognize the corresponding metacity bug.
*** Bug 147699 has been marked as a duplicate of this bug. ***
This seems to be the same bug as http://bugzilla.gnome.org/show_bug.cgi?id=101190, which is unfortunately a won't fix. Would it make sense to work around this in gtk (e.g. grabbing focus after closing the popup)? It would be best if someone could come up with a way to fix #101190, of course. *** This bug has been marked as a duplicate of 101190 ***
No need to work around it in gtk+; it appears that the metacity patch to fix this is rather simple (see bug 101190).