After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 347541 - gtkfilechooser shouldn't emit selection-changed if the selection hasn't been changed.
gtkfilechooser shouldn't emit selection-changed if the selection hasn't been ...
Status: RESOLVED DUPLICATE of bug 327243
Product: gtk+
Classification: Platform
Component: Widget: GtkFileChooser
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
Federico Mena Quintero
Depends on:
Blocks:
 
 
Reported: 2006-07-14 17:56 UTC by Ray Strode [halfline]
Modified: 2007-01-26 15:56 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Ray Strode [halfline] 2006-07-14 17:56:14 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.
Comment 1 Federico Mena Quintero 2007-01-25 20:57:40 UTC
Is this the same as bug #327243?
Comment 2 Ray Strode [halfline] 2007-01-26 15:56:48 UTC
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 ***