GNOME Bugzilla – Bug 708984
Completion popup window in GtkEntry not functional
Last modified: 2013-11-12 11:06:53 UTC
Utilizing the broadway backend, auto-complete functionality is not working as intended. The inline completion works fine, however, when a popup appears with the potential matches after keyboard input, it immediately disappears. Obviously this is not the intended behavior and operates correctly on an X11 backend.
Created attachment 258922 [details] Test program The attached program is a simple testcase showing the issue; it's just a window with a combobox which has a GtkEntry with completion setup. The completion popup window gets shown and immediately hidden. The same issue can be reproduced in gtk3-demo's "Entry Completion" example.
The root issue seems to be that the Broadway backend emits a 'BROADWAY_EVENT_LEAVE' event as soon as a character is entered in the entry; which triggers a focus-out event in the GtkEntry, which in turn pops-down the completion (the _gtk_entry_completion_popdown() call in gtk_entry_focus_out()).
The sequence of events seems to go as follows: * User clicks in the GtkEntry, which grabs pointer * User enters character in the GtkEntry, a new popup window is shown * The new popup window grabs pointer, and this triggers the release of the pointer in the GtkEntry (broadway.js:doGrab; when the pointer is grabbed by another window, an implicit grab release event is generated for the window which was holding the grab). * The pointer release in the GtkEntry triggers a focus-out event * The GtkEntry hides the popup window due to the focus-out * The popup window releases the pointer as it's being hidden * The GtkEntry re-grabs the pointer In other words, the new popup grabbing the pointer when shown will make the entry to tell the popup to hide right away; so the popup is shown for a very little time.
The issue seems to be pretty complex to fix, as the root issue keeps being that broadway tries to mimic a focus-follows-mouse behaviour (i.e. wherever the mouse goes, also goes the focus). In the case of the GtkEntry, it will explicitly close the completion popup window whenever the entry loses focus. And as shown in the previous comment, showing the popup itself switches the grab (and the focus) from the entry to the popup, therefore causing the focus-out-event in the entry which triggers the popup closing. Among other things I've tried these two things: 1) Don't notify focus changes with TEMP windows: * Avoid triggering GDK_FOCUS_CHANGE event in BROADWAY_EVENT_ENTER when the event window is a TEMP window. * Avoid triggering GDK_FOCUS_CHANGE event in BROADWAY_EVENT_LEAVE if the window to where the focus is leaving (known only for GDK_CROSSING_GRAB/UNGRAB cases, after adding a new variable in BroadwayInputCrossingMsg to handle the other window's id) is a TEMP window. This fix would let the entry show the popup (as there wouldn't be a focus-out-event in the entry when the grab passes from entry to popup). But then if the mouse moves to the popup window, it would be closed again (as we get a onMouseOut() which triggers a BROADWAY_EVENT_LEAVE without knowing to which window the mouse is moving). So not ideal... 2) I had to try the case where the GtkEntry just doesn't explicitly close the popup during focus-out-event, and of course, the behaviour is perfect in that case. The popup is shown and is fully usable. But this is a change in GTK, not in GDK, and not closing the popup during focus-out-event will break other backends I guess. Ideas?
Moving broadway to click-to-focus seems like an obvious solution. The reason its currently focus-follows-mouse is purely laziness on my side when i initially coded this. (i.e. it just happened so i could get something going.) click-to-focus is generally easier to handle and is the default in most OSes, so most likely expected by users.
Created attachment 259132 [details] [review] Patch. The attached patch tries to implement click-to-focus instead of focus-follows-mouse. How does it look like?
Looks good! I've been testing it for the better part of the last hour; auto-complete window works perfectly and I don't see any unexpected behavior. In fact, the UI itself seems to feel more naturally responsive. Also, there was another window focus bug that was previously manifesting itself randomly that I cannot (currently) reproduce now. So, I'd say this is a win-win-win.
Hey Terrence; I'm re-opening the bug because it didn't get merged to the git repository yet. Let's see what Alex says about it as the patch might be missing things.
Cool! I pushed a slightly modified version where the focus is a global rather than per-client property (like in X).