GNOME Bugzilla – Bug 645065
GtkFileChooserButton doesn't handle closing its dialog correctly
Last modified: 2012-08-31 17:25:16 UTC
Use gtk-demo to reproduce. 1. select a file and accept 2. open the dialog again, then close it Result: filename set to (NULL) Expected: filename unchanged Previously, I was convinced both closing and canceling had that effect, but probably either I was seeing things or that recent hidden files fix helped with canceling.
If I remove g_signal_emit_by_name (dialog, "response", GTK_RESPONSE_DELETE_EVENT); from dialog_delete_event_cb (gtk/gtkfilechooserbutton.c), making it simply return TRUE, the button works as I'd expect it to, but I'm unsure if that's the proper way of fixing this bug. On unrelated note: those gdk_threads fixes that went into 2.24.4 produce warnings due to missing include: gtksearchenginetracker.c:229:3: warning: implicit declaration of function 'gdk_threads_enter' gtksearchenginetracker.c:240:7: warning: implicit declaration of function 'gdk_threads_leave'
Well, nothing new as far as the fixing goes, just reporting that I've installed 3.2.1 a few days ago and it's affected by this bug too.
Well, as of 3.4.0, it's consistent again - both canceling *and* closing unsets the name. If this is the intended behavior (which would be kind of broken - "no action taken" should not be equal to "unset the name"), it should be documented.
You are right; this is broken :) The selected name shouldn't change if you cancel or close the dialog.
Ok I just tested this as well. Just run gtk3-demo and choose the "Pickers" demo. In File section click on the chooser and open any file. Then click on the file chooser it again and cancel the dialog. Result, the file name will be unset. I request to mark this bug report as confirmed.
The following debug output was caputed when being in response callback after pressing the CANCEL button: Breakpoint 1, dialog_response_cb (dialog=0x26ad1c0, response=-6, user_data=0x2730190) at gtkfilechooserbutton.c:2680 2680 GtkFileChooserButton *button = GTK_FILE_CHOOSER_BUTTON (user_data); (gdb) n 2681 GtkFileChooserButtonPrivate *priv = button->priv; (gdb) n 2683 if (response == GTK_RESPONSE_ACCEPT || (gdb) n 2689 else if (priv->old_file) (gdb) n 2691 switch (gtk_file_chooser_get_action (GTK_FILE_CHOOSER (dialog))) (gdb) p g_file_get_basename(priv->old_file) $11 = 0x26a81c0 "testfile.html" (gdb) p gtk_file_chooser_get_filename(user_data) $12 = (gchar *) 0x2abe940 "/media/Downloads/quantal-desktop-amd64.iso" (gdb) n [Thread 0x7faaebfff700 (LWP 19957) exited] 2694 gtk_file_chooser_select_file (GTK_FILE_CHOOSER (dialog), priv->old_file, NULL); (gdb) n [New Thread 0x7faaebfff700 (LWP 19966)] 2695 break; (gdb) p gtk_file_chooser_get_filename(user_data) $13 = (gchar *) 0x0 as this debug output shows, the bug happens within the gtk_file_chooser_select_File function, when that function returns, the file which is selected in the file chooser should not be null but testfile.html.
Oh, and this bug only happens if the folders of the last selected file and the currently selected file are different, for example: 1. Go to a folder (e.g Desktop) 2. Select "test1.pdf" 3. OK 4. Click filechooserbutton again 5. Go to same folder (e.g Desktop) 6. Select "someotherfile.pdf" 7. CANCEL The button still shows "test1.pdf" and not null.
Created attachment 223092 [details] [review] Correctly update the filename if user clicks cancel Federico, can you try this?
Thanks for figuring this out! I pushed your patch to master as afc7466dfd, and to gtk-3-4 as a1bcab9f8.
(In reply to comment #9) > Thanks for figuring this out! I pushed your patch to master as afc7466dfd, and > to gtk-3-4 as a1bcab9f8. Any chance of pushing to 2.24 ?