GNOME Bugzilla – Bug 347541
gtkfilechooser shouldn't emit selection-changed if the selection hasn't been changed.
Last modified: 2007-01-26 15:56:48 UTC
So I'm running into some GDM code that connects to the selection-changed signal of a file chooser button, and under certain circumstances runs code like: g_signal_handlers_disconnect_by_func (file_chooser, handler, file_chooser); gtk_file_chooser_set_filename (GTK_FILE_CHOOSER (file_chooser), filename); g_signal_connect (G_OBJECT (file_chooser), "selection-changed", G_CALLBACK (handler), file_chooser); This is causing recursion. Presumably the disconnect_by_func is there to prevent the recursion. This must have broke when merging the async branch. The file chooser chould choose to not emit a selection-changed signal if the app calls set_filename with a filename that's already selected. That would keep code like this working.
Is this the same as bug #327243?
I think so. So I think that before the async changes landed, calling set_filename would cause selection-changed to be emitted before returning. Now calling set_filename will cause selection-changed to be emitted after returning to the mainloop. This means that if the code connects to selection-changed before returning to the mainloop (but after calling set_filename) then the handler will get called spuriously. Existing code is working under the assumption that set_filename is a synchronous operation. *** This bug has been marked as a duplicate of 327243 ***