GNOME Bugzilla – Bug 86700
Nonworking combobox's list entry selection
Last modified: 2011-02-04 16:10:07 UTC
The combobox's list selection in some case don't works. A program to reproduce the bug is added. To reproduce the bug: 1) Click on "Button" 2) Rolldown the combo list, wait about 10 sec rollup the combo list, wait about 10 sec, rolldown again & select bug from list. 3) Click on "Button"4) Rolldown the combo list, wait about 10 sec rollup the combo list, wait about 10 sec, rolldown again & select bug from list, and the entry of the combobox stays empty. Note: if you do fast the step sometimes the bug remain hidden. to compile: save the snippet as some.cpp and type "gcc some.cpp `gtk-config --cflags --libs` --- code snippet start --- #include <gtk/gtk.h> #include <string.h> GtkWidget *combo; void empty_combo(GtkWidget *widget, gpointer) { gtk_entry_set_text(GTK_ENTRY(GTK_COMBO(combo)->entry), ""); } int main(int argc, char *argv[]) { gtk_init(&argc, &argv); GtkWidget *window = gtk_window_new(GTK_WINDOW_TOPLEVEL); GtkWidget *vbox = gtk_vbox_new(true, 5); combo = gtk_combo_new(); GtkWidget *button = gtk_button_new_with_label("Button"); GList *list = (GList*)NULL; char *string = strdup("bug"); list = g_list_append(list, string); gtk_combo_set_popdown_strings(GTK_COMBO(combo), list); gtk_combo_set_value_in_list(GTK_COMBO(combo), true, true); gtk_signal_connect(GTK_OBJECT(button), "clicked", GTK_SIGNAL_FUNC(empty_combo), 0); gtk_container_add(GTK_CONTAINER(window), vbox); gtk_box_pack_start(GTK_BOX(vbox), combo, true, true, 0); gtk_box_pack_start(GTK_BOX(vbox), button, true, true, 0); gtk_widget_show_all(window); gtk_main(); return 0; } --- end of code snippet ---
Created attachment 9512 [details] [review] Probably good solution
I assume that you didn't mean to resolve this? (Resolved/fixd this means "fixed in the GTK+ codebase", not "I have a fix". Resolved bugs need no further action.) Can you explain how the selection doesn't work? Trying to reproduce bugs without an idea of what you are trying to see can be hard.
Sorry, I probably missunderstood, the states :) The selection when it does not work shows the following thing: You select the line from the list and after you click on the line the list disappears, but the value of the line don't appear in the entry's text field.
Can you explain why your patch fixes the problem? On first glance, it looks completely unrelated. (I'd like to find a different fix than your suggested one, because I think your fix is introducing dependencies that shouldn't be there. So, I'd like to understand the problem.)
I dont know why it does not work when the patch isnt applied. I didnt traced the line out with gdb, instead with printing out parameters and commenting out lines. It seems if the if part isn't executed (the if touched by the patch) then the bug is solved. But we need on some cases the if part. In the comment there is a line that if case if for gtk_plug, so I made this a test case too, not only in the comment. Seems working. (Tested more than 10000 times since the modification at a customer.)
I investigated this a bit. The problem can be reproduced with any combo box, e.g. the one in the "entry" example of testgtk. Steps to reproduce: 1) Clear the entry 2) Pop up the list by clicking on the button. Notice that no listitem is selected, but one is marked as last_focus_child. 3) Now click-and-release-without-intervening-motion on the last_focus_child. 4) The list pops down, but the item you clicked on does not appear in the entry. 5) If you repeat the sequence, but click on any other listitem than the last_focus_child, it will appear in the entry. The problem is that the button press in 3) doesn't cause a selection changed signal to be emitted, since the listitem we click on is already the focus_child of the list. A simple fix would be to manually select the focus_child when popping down the list in response to a release event. See the appended patch.
Created attachment 11674 [details] [review] patch
I don't really understand the reference to 'last_focus_child' since I don't see anywhere that last_focus_child affects the mouse selection for single selection.
Sorry, I think my terminology was inconsistent here, because I was a bit confused by focus_child vs. last_focus_child. I think I'm only talking about focus_child here (visually: the listitem which has the focus indication drawn around it, but is not selected).
So, the bug can be boiled down to a GtkList bug: If a GtkList is in the BROWSE selection mode, and a row is the focus child but not selected, then clicking on that row doesn't work. Theoretically, we should fix _that_ bug, but since GtkList is deprecated and the selection code is a real horror, I'm not very inclined to to do so. So, fixing it at the GtkCombo level seems right to me. However, I noticed a _different_ bug in GtkCombo while testing this bug that inspired me to a somewhat different fix in GtkCombo. The other bug was: When the initial string in the entry doesn't match any string in the list, then when the list is popped up, the first item selected. The reason for this bug is that when a GtkWindow is shown, if there is no focus widget at all, it focus the first widget in the window, which happens to be the list item. So, the solution that this inspires is, when popping up the list, focus the GtkList itself (so that there is some widget focused) instead of focusing any of the children. If we do every time there is no selected child, even when there is a current focus widget, then we fix this bug as well. Focusing the list instead of a child is definitely a hack, but in practice GtkList seems robust against it.
Created attachment 11769 [details] [review] Proposed alternate fix
Your patch seems to work equally well. Fixes both bugs for me.
Tue Oct 22 20:02:22 2002 Owen Taylor <otaylor@redhat.com> * gtk/gtkcombo.c: When popping up the list without any selected items, hack the focus on the list to avoid triggering a bug in GtkList when clicking on focused-but-not-selected items (#86700, Zimler Attila, Matthias Clasen) and to keep GtkWindow from selecting the first item.