How should Epiphany know that the file being downloaded is the same file as the one on disk that accidentally has the same filename? The average webserver doesn't send an MD5 hash first does it?

However, I could support a Skip/Overwrite dialog when the auto download&open preference is disabled.

Setting severity:enhancement.

Created attachment 94937 [details] [review]
first attempt for a fix

The attached patch is a first attempt to have the dialog proposed by Reinout.
I think that the patch needs some more work though...for example, I did not find a way to get the parentWindow from inside MozDownload.cpp (is it just me or Mozilla code is way harder to hack than Gnome one?), so the dialog has the parent set to NULL.
Comments and suggestions are really welcomed!

@Cosimo, I haven't checked your patch yet (could you attach a screenshot?) but I'd like to point out that you might want to look at bug 341666 and its patch first.

Reinout: here is a screenshot
http://anarki.lilik.it/media/my/ephy_dialog.png
(Salva come = Save As)
I think the logic behind the two patches is slightly different, and both could be viable ways. The dialog in the screenshot will always pop-up when you use the "Download" function (obviously not when you use Save as...) and epiphany will find that a file with that name exists in your downloads directory, both if you use the auto open function and if you don't.

Cosimo: the point of the auto download & open feature is that it's a way of saying "Don't bother me with uninteresting questions, just show me the file!". Popping up this dialog when a file under the same name already exists, defeats that purpose. The one case where your dialog *would* be useful is when auto download is enabled and Epiphany doesn't recognize the MIME type. There's simply no use in popping up the download folder and having the user manually trash the duplicate, compared to showing this dialog.

Now, maybe Epiphany could somehow keep track of files it downloaded recently (via the Recent files stuff - Diego??) and minimize the possibility of duplicate downloading that way. Not just the filename but the URL where it came from should be stored. Maybe the Imran's history backend could help with that. But I digress.

Actually I was hoping that Josselin's patch and yours could be merged into one- do you think that's feasible?

Your editor seems to mix tabs and spaces for indentation... :)

+	BuildDownloadPath (filename, getter_AddRefs (destFile), &show_dialog);
+	if (show_dialog)
+	{
+		ShowSaveDialog (key, filename);
+	}
+	else 
+	{
+		g_free (filename);
+	}
+	
+	return NS_OK;

That should return the rv of BuildDownloadPath, not always NS_OK.

+nsresult StartDownload (char *path, nsILocalFile **_retval)
 {
-        int i;
-        static const char * const compression[] = {".gz", ".bz2", ".Z", ".lz", NULL};
-
-        for (i = 0; compression[i] != NULL; i++)
-        {
-                if (g_str_has_suffix (filename, compression[i]))
-                        return compression[i];
-        }
+    nsCOMPtr <nsILocalFile> destFile (do_CreateInstance(NS_LOCAL_FILE_CONTRACTID));
+   	NS_ENSURE_TRUE (destFile, NS_ERROR_FAILURE);
 
-        return NULL;
+   	destFile->InitWithNativePath (nsCString (path));
+    g_free (path);

It's a bit unusual for a function to consume its input (freeing |path| here)...

+        dialog = gtk_message_dialog_new
+            (NULL,

We really should have a parent for this dialogue, if possible...

In case we have shown a filepicker already, we should have done this checking while the filepicker was up, not afterwards (the confirm-overwrite thingy on gtkfilechooser).

+        response = gtk_dialog_run (GTK_DIALOG (dialog));

If we really really need to run this dialogue, you need to protect this with a AutoJSContextStack instance (and if we have a parent DOM window, with a AutoWindowModalState instance). See other code in embed/mozilla/ using gtk_dialog_run on how to use them.

Reality check.

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/epiphany/issues/106.