summaryrefslogtreecommitdiff
path: root/browser.c
diff options
context:
space:
mode:
authorPeter Hofmann <scm@uninformativ.de>2014-08-09 18:25:30 +0200
committerPeter Hofmann <scm@uninformativ.de>2014-08-09 18:25:30 +0200
commit12606cb8458f5d23f0e407f08eb31b492dd2b4ea (patch)
tree623a1e3f58ab6404218f1d19391380be1790e117 /browser.c
parent7e42c6b79fdd54961401c9be97f20e507eb3b2a0 (diff)
downloadlariza-12606cb8458f5d23f0e407f08eb31b492dd2b4ea.tar.gz
Minor improvement to changed_download_progress()
I checked WebKit's source code: webkit_download_get_destination_uri() never returns NULL in lariza. It's because we set the destination URI in the signal handler for the download request. If g_filename_from_uri() really returned NULL for some reason, then it'd be just plain wrong to announce the "suggested file name", because we might be saving the download ... somewhere else. I doubt this function ever returns NULL in lariza, though, but you never know. So, now, the download manager will correctly show the URI if the destination URI is "unknown".
Diffstat (limited to 'browser.c')
-rw-r--r--browser.c3
1 files changed, 1 insertions, 2 deletions
diff --git a/browser.c b/browser.c
index 2f1676a..47ac63d 100644
--- a/browser.c
+++ b/browser.c
@@ -372,8 +372,7 @@ changed_download_progress(GObject *obj, GParamSpec *pspec, gpointer data)
/* This really should not happen because WebKit uses that URI to
* write to a file... */
fprintf(stderr, __NAME__": Could not construct file name from URI!\n");
- t = g_strdup_printf("%s (%.0f%%)",
- webkit_download_get_suggested_filename(download), p);
+ t = g_strdup_printf("%s (%.0f%%)", webkit_download_get_uri(download), p);
}
else
{