GNOME Bugzilla – Bug 776793
GtkComboBox with appears-as-list doesn't receive mouse events from a dialog window
Last modified: 2017-10-04 20:36:30 UTC
When used in a dialog window, a GtkComboBox with the "appears-as-list" property does not work. Mouse events in the list (GtkTreeView) are ignored, although key press events do work. This happens with GTK 3.x (3.18.9 through 3.22.4 at least) but not with GTK 2.22.10. I see it happening in both Windows (msys2 with GTK 3.22.4) and Linux (Fedora 23 with GTK 3.18.9). It does not happen for a GtkComboBox located in the program's main window, nor for a menu-style combo with "appears-as-list" not set. See also bug 743683 - the symptoms are the same but it does not seem to be the same problem since that one happens in the main window and it appears to be fixed in 3.22.4 where this problem still happens.
Created attachment 342746 [details] A small program that demonstrates the problem I've attached a small program that demonstrates the problem: In the main window on the left it has a menu-style combo box and on the right a list-style combo box. These both work fine. Below these are buttons that open a dialog window containing the same. The left button opens a dialog with a menu-style combo that works fine, the right button opens a dialog with a list-style combo that does not work.
After some debugging I seem to have found the problem. When the combo box is located in a dialog window the mouse events are presumably going to the dialog window's main event loop, and it does not appear to be passing them through to the popup window opened for the "appears-as-list" combo by function gtk_combo_box_set_popup_widget. Making the combo box's popup window modal fixes this, and then the mouse events are passed to it from the parent dialog window and the list combo works properly. I don't know if there is a bug somewhere else in GTK 3 that is preventing a dialog window from passing mouse events to a non-modal child popup window, or if that is deliberate and the bug is here in not making this popup window modal? I will supply a patch shortly with a fix for the latter.
Created attachment 342782 [details] [review] Patch that fixes this problem by making the list combo box's popup window modal.
Created attachment 358304 [details] test case (extracted from tar.gz)
(In reply to Ian Puleston from comment #2) > I don't know if there is a bug somewhere else in GTK 3 that is preventing a > dialog window from passing mouse events to a non-modal child popup window, > or if that is deliberate and the bug is here in not making this popup window > modal? The bug is that nested main loops are used at all. :) They're a bad idea that has been slated for removal from GTK+ for years and will hopefully be gone soon. You could presumably work around this by using your dialog through its ::response signal instead of gtk_dialog_run()ing it. Anyway, maybe someone else can review the patch. I've not tested it yet, nor tried to wrap my brain around whether it can conceivably break some other scenario... though appears-as-list breaks plenty other things already, so what's one more? :(
They probably need their own bugs to add to the pile, but for now: I note also the following problems with the non-dialog appear-as-list combo in your test case: * focussing with the keyboard then using an activating key results in the button being depressed, but the popup not being shown... * the popup doesn't seem closable by clicking outwith it No wonder this mode was deprecated. :S
Review of attachment 342782 [details] [review]: ::: gtk+-3.22.4/gtk/gtkcombobox.c @@ +1876,3 @@ gtk_window_group_add_window (gtk_window_get_group (GTK_WINDOW (toplevel)), GTK_WINDOW (priv->popup_window)); + gtk_window_set_modal (GTK_WINDOW (priv->popup_window), TRUE); I would set this unconditionally and keep this if block for only stuff that's contingent on toplevel, but I dunno if it makes much difference in practice. I'm working on a set of patches for list mode at the moment, and so far it seems making popup_window modal will also fix another one of them into the bargain: https://bugzilla.gnome.org/show_bug.cgi?id=738387
*** Bug 738387 has been marked as a duplicate of this bug. ***
Created attachment 358534 [details] [review] ComboBox: List-mode popup_window needs to be modal This fixes at least two bugs: failure to close the popup when clicking out of it, and failing to receive mouse input in a CB in a modal window – of which the latter seemingly can cause a fatal stuck grab. https://bugzilla.gnome.org/show_bug.cgi?id=738387
(In reply to Daniel Boles from comment #9) > Created attachment 358534 [details] [review] [review] > ComboBox: List-mode popup_window needs to be modal In fact I think all we need to do is to restore the missing gdk_grab_add(priv->popup_window), which is present in GTK+ 2 - explaining why that's not affected by this - but lost in GTK+ 3. gtk_window_show() calls gdk_grab_add() if the window is modal.
This appears to be fixed by https://git.gnome.org/browse/gtk+/commit/?h=gtk-3-22&id=13017239055dc492f7e5cdeae63f01e6e820da4e Thanks for the report!
*** Bug 743683 has been marked as a duplicate of this bug. ***
Hey, I think you were right in the first place! So I'll probably be reverting my other commit and pushing the tweaked patch from Comment 9 soon, after some more tests to see if it doesn't break another 3 things... as seems to be the way in list mode.