FileChooserButton refilters model in :popped-up handler, breaking assumptions of ComboBox
Submitted by Daniel Boles
GtkFileChooserButton has a [None] item, indicating nothing selected. The model it sets on its internal GtkComboBox is a GtkTreeModelFilter. This exists to - among other things - show the [None] item when the popup is popped-down but hide it while popping up, as it was judged to be unwanted in the popup list/menu.
The problem here is that the ComboBox needs to do its own stuff with the model while popping up/down. If the user alters the model in a conflicting way, ComboBox uses invalid iterators to the model, causing crashes. FileChooserButton in both modes was breaking assumptions caused by ComboBox doing the following:
getting the active item BEFORE popping up the GtkMenu in menu mode, to centre it over the button, then selecting that item in the menu AFTER it pops up
- worked around by commit e98e6f73
getting the clicked iter BEFORE popping down, but only using it AFTER popping down, to avoid potentially confusing grabs in users' ::changed handlers
- worked around by commit 696b9a5d
(hashes are for GTK+ 3, but these problems also exist in 2 and 4 where relevant)
These patches may interfere with expectations elsewhere, and they shouldn't be necessary: FileChooserButton or any other user of ComboBox should not pull the model out from under the ComboBox while it's doing internal housekeeping.
By letting them continue to do so, we incur the hassle of having to work around the resulting problems elsewhere, which may break different scenarios in the process. The real fix is to stop tolerating widgets that do this, and fix them.
(filing under FileChooser as it's closest; hopefully the FCB is the only internal user that does this. If it's not, this will need to be a general bug)