GNOME Bugzilla – Bug 787274
ComboBox in appears-as-list-mode: Gtk-CRITICAL when popping down with scrollbar fully shown
Last modified: 2017-10-04 22:22:45 UTC
With a GtkComboBox having the style property appears-as-list set to TRUE, any time you release and cause the CB to popdown, when the Scrollbar was fully shown due to having started a drag, you get this: > (testcombochange:28421): Gtk-CRITICAL **: gtk_css_gadget_queue_allocate: assertion 'GTK_IS_CSS_GADGET (gadget)' failed backtrace: Thread 1 "testcombochange" received signal SIGTRAP, Trace/breakpoint trap. _g_log_abort (breakpoint=1) at /home/daniel/jhbuild/checkout/gnome/glib/glib/gmessages.c:554 warning: Source file is more recent than executable. 554 } (ins)(gdb) bt
+ Trace 237926
Reverting Commit 9b032073cbcf5aadbeb4b74f0cf662a9fa5f5530 from Bug 782870 results in this critical going away. Carlos, any thoughts? Knowing what ComboBox in appears-as-list mode is like, it's almost certainly the one in the wrong, but I don't really know where to begin. :)
Uhm, not sure by quickly looking at the bt/code... It's weird that priv->grab_location is non-NULL but invalid, this var does not take a ref, so it's possible though that the grab_location is left pointing to a just destroyed GtkCssGadget. Maybe the grab should be undone at the time of destroying the gadget, since that's what is conceptually holding the grab. How are you popping down the combobox?
Thanks for looking! (In reply to Carlos Garnacho from comment #2) > How are you popping down the combobox? 1: Click and hold on the scrollbar to start a drag 2: Move the pointer to a position that would cause a popdown, and release: a: on a treeview item b: outwith the popup_window 3: That causes the window to popdown, and the critical to appear.
Also, need to test this on Linux later, but here on Windows, it's really easy to accidentally move out of the scrollbar, then release and the popup closes. Not sure if that's to do with the event widget checks in button_release(), or maybe a failed grab on the scrollbar.
(In reply to Carlos Garnacho from comment #2) > Uhm, not sure by quickly looking at the bt/code... It's weird that > priv->grab_location is non-NULL but invalid, this var does not take a ref, > so it's possible though that the grab_location is left pointing to a just > destroyed GtkCssGadget. > > Maybe the grab should be undone at the time of destroying the gadget, since > that's what is conceptually holding the grab. Why would any of the involved gadgets be destroyed? GtkComboBox doesn't rebuild its ScrolledWindow except when changing modes, and it's not clear to me that GtkRange rebuilds any of the gadgets that would be involved in this case.
Ugh, OK, my revert commit 13017239055dc492f7e5cdeae63f01e6e820da4e probably fixed its mentioned bugs purely out of coincidence, and it's not the real fix for them, as it: * breaks grabs, as seen in Comment 4; the bar seemingly just doesn't get one... like restoring the "superfluous GTK+" grabs actually means we get NO grab. * and, apparently, introduces this critical too. :( List-mode ComboBoxes could fuel a lifetime of patches.
So there's my next attempt... https://git.gnome.org/browse/gtk+/commit/?h=gtk-3-22&id=b92234be08d1575aeb6957be656a09f1e4f624c2 https://git.gnome.org/browse/gtk+/commit/?h=gtk-3-22&id=6c5b2846156ab04fa409ac11353a2f9c71b2ae7c