GNOME Bugzilla – Bug 598167
'Open' button in download dialog has gone away
Last modified: 2009-10-27 12:20:18 UTC
In earlier versions of epiphany, the download dialog offered both 'save as...' and 'open' buttons. In 2.28 the 'open' button has changed to 'download'. This makes certain uses of the browser more annoying; for instance, if I follow a PDF link, I want to have it saved to a temporary location and have my PDF reader spawned; or if I click a link on http://somafm.com/ I want to have my music player open the chosen Internet radio station. Now, I have to save such files to disk, hunt for them in the file manager, and double-click them. I don't have 'automatically download and open files' enabled in preferences, becase there are files that I do want to actually 'download' (to my mind, that means save to a permanent location) when a web site serves them to me. This is somewhat similar to, but not exactly the same as bug 583426.
What distro are you using? I remember Debian was using a special patch to alter Epiphany's behaviour in this regard.
Indeed, I'm using Debian; but the download dialog patch was dropped in revision 2.28.0-1 of the debian packaging. I don't think there are any more patches that would effect the download dialog. But if you want to check you can see the list at: http://svn.debian.org/wsvn/pkg-gnome/desktop/unstable/epiphany-browser/debian/patches/#_desktop_unstable_epiphany-browser_debian_patches_
(In reply to comment #2) > Indeed, I'm using Debian; but the download dialog patch was dropped in revision > 2.28.0-1 of the debian packaging. Then, most likely, that is the reason that Epiphany is showing default behaviour now!
Wait, the Open button was never the default behaviour? Then I guess this becomes a feature request. :)
(In reply to comment #4) > Wait, the Open button was never the default behaviour? Then I guess this > becomes a feature request. :) Then probably we should close this as a duplicate of bug 341666. Agreed?
I'm not really sure. The discussion there seems rather long winded and out of date. No-one really talks about the 'open' button, except to mention that epiphany gives you an Open button instead of a Download button for recognised MIME types... that doesn't currently happen for me though!
*** Bug 598520 has been marked as a duplicate of this bug. ***
Ok, so apparently this was a Debian specific patch so far? Well, IMHO the download dialog should look like For known types with a known application that supports it: ---------------------------------------- | Blablabla | | [Open] [Save as] [Cancel] | ---------------------------------------- For everything else: ---------------------------------------- | Blablabla | | [Save as] [Cancel] | ---------------------------------------- The current -------------------------------------------- | Blablabla | | [Download] [Save as] [Cancel] | -------------------------------------------- dialog is just confusing (where does download save the file? What's the difference between downloading and saving?). But that's really bug #341666.
(In reply to comment #8) > For everything else: > ---------------------------------------- > | Blablabla | > | [Save as] [Cancel] | > ---------------------------------------- The big disadvantage here is that you're forcing users to go through the filechooser time and again. > The current dialog is just confusing (where does download save the file? > What's the difference between downloading and saving?). But that's really bug > #341666. Obviously, 'Download' downloads to the download folder specified in the Preferences. I could imagine the 'Save as...' label renamed to 'Download to...', though.
Just to clarify, the open button was not a Debian addition, but it depends on Epiphany knowing the mime type of the file early in the download process. Until recently this was not possible with webkit, so I could not reimplement that part of the dialog. This is somewhere in my TODO list =D. Here's the relevant code, and comments (embed/ephy-embed.c:653): /* FIXME: we still have no way of getting the content type from * webkit yet; we need to have a proper WebKitNetworkRequest * implementation to do this here; see * https://bugs.webkit.org/show_bug.cgi?id=18608 */ helper_app = NULL; mime_description = NULL; mime_permission = EPHY_MIME_PERMISSION_SAFE; if (mime_description == NULL) { mime_description = g_strdup (C_("file type", "Unknown")); action = DOWNLOAD_ACTION_OPEN_LOCATION; } /* OPEN will never happen here, for now; see comment about * WebKitNetworkRequest above! */
Created attachment 146224 [details] [review] proposed fix This needs an addition to WebKitGTK+ as well: https://bugs.webkit.org/show_bug.cgi?id=30759
Review of attachment 146224 [details] [review]: ::: embed/ephy-embed.c @@ +658,3 @@ + message = webkit_network_response_get_message (response); + response = webkit_download_get_network_response (download); + Is the response always guaranteed to be there? Otherwise you should check. @@ +773,3 @@ confirm_action_from_mime (web_view, download, DOWNLOAD_ACTION_DOWNLOAD); } g_object_ref (download); /* balanced in confirm_action_response_cb */ Other than that looks fine, feel free to commit when the WebKitGTK+ patch lands.
Review of attachment 146224 [details] [review]: ::: embed/ephy-embed.c @@ +658,3 @@ + + response = webkit_download_get_network_response (download); + message = webkit_network_response_get_message (response); At this point in time, it should always exist. The download status change we are looking for here only happens after the response has been received, and set_response has, thus, been already called on the download.
Just want to say thanks for fixing this so quickly! epiphany-webkit is really shaping up! :D
Just pushed 009be331694b442dd859f49c7f02bdef498621ff to master. I fixed the const nature of the string returned by soup_message_headers_get_content_type. I was first using get_one(), and forgot to fix that. This fix will be in 2.29.1.
*** Bug 598044 has been marked as a duplicate of this bug. ***