GNOME Bugzilla – Bug 696498
can't set download folder
Last modified: 2013-06-22 00:39:36 UTC
I'm running Epiphany 3.7.92 on Ubuntu 13.04 (Raring). Epiphany won't let me set the download folder. When I open the Preferences window, the "Download folder:" item there appears empty. If I select a folder such as Desktop, then when I close the Preferences window and open it again, "Download folder" appears empty once again, and downloads still show up in my Downloads folder, not the folder I chose. I wonder whether this bug is specific to Ubuntu.
This works if you open the file chooser and select a folder, but not if you select it from the initial dropdown. The "current-folder-changed" signal is not emitted in the second case. Looks like a GTK+ bug to me, reassigning.
On Ubuntu at least, this doesn't work even if I open the file chooser and select a folder. For me, even in that case if I close the Preferences window and reopen it then "Download folder" is empty again.
Aha - if I open the file chooser and select a folder then Epiphany actually *does* use that folder for saving downloads. The folder is not displayed in the Preferences window, however.
(In reply to comment #3) > Aha - if I open the file chooser and select a folder then Epiphany actually > *does* use that folder for saving downloads. The folder is not displayed in > the Preferences window, however. For me the folder *is* displayed in the file chooser button. I guess we are just using different (but both broken) versions of GTK+. This used to work until relatively recently, so I assume it is related to the latest changes in the widget that Federico blogged about. FWIW I use the gtk-3-8 branch as of today (5442023b80).
Interesting. I'm using libgtk 3.7.12 (including the various GTK patches that Ubuntu applies).
Looks like this is related to or maybe a duplicate of bug 695216 .
Created attachment 247371 [details] [review] Bug 696498 - Emit "file-set" on select file in GtkFileChooserButton Otherwise, when the combo box changes and calls select file the combo box is updated but the signal is not emitted, unlike when the file is selected in the dialog.
Created attachment 247372 [details] [review] Bug 696498 - Connect to the correct GtkFileChooserButton signal See https://git.gnome.org/browse/gtk+/commit/?id=45ad8a06ad511ad95a74172172b9fe459bc666ad
(In reply to comment #7) > Created an attachment (id=247371) [details] [review] > Bug 696498 - Emit "file-set" on select file in GtkFileChooserButton > > Otherwise, when the combo box changes and calls select file > the combo box is updated but the signal is not emitted, unlike > when the file is selected in the dialog. Thanks! Good catch. I've put the signal emission in a slightly better place, where it is *actually* the user that changed the selection, as opposed to any programmatic change through the file chooser's API. This is in the master branch in commit 32e75adf6, and in the gtk-3-8 branch in commit 22ca91ffa. At this point I don't remember while GtkFileChooserButton makes a distinction between user-initiated changes and programmatic ones. I think applications are better off just listening for the "selection-changed" signal; Epiphany should definitely do that. Epiphany and other applications should *NOT* use "current-folder-changed" to detect changes in the selection. That signal only means, "the user changed directories in the file chooser dialog", not necessarily that the *selection* has been changed. I've just pushed a fix for Epiphany to use "selection-changed".