GNOME Bugzilla – Bug 466718
Confusing/duplicate buttons when downloading a file with unknown mime type
Last modified: 2007-08-14 20:40:49 UTC
Please describe the problem: When you download a file with an unknown mime type, and you have set Epiphany not to download and open files automatically, then a dialog is shown, which gives you three buttons: Save As, Cancel and Download. Apparently Download saves the file in the default set download location (a functionality which I have disabled!), while Save As asks where you want to save. One of these two buttons is superfluous. There should only be one of them, either Download if the user has set it to automatically download and open files, either Save as if the user has unchecked this function Steps to reproduce: Open URL http://bugzilla.kernel.org/attachment.cgi?id=12385&action=view Actual results: A dialog appears: Download this file? File Type: “unknown”. You have no application able to open “ali.zip”. You can download it instead. Buttons: Save As, Cancel, Download Expected results: In my case, because I have configured Epiphany not to automatically download and open files, it should only show Save As and Cancel. If the user has left the default configuration to automatically download and open files, there should only be Download and Cancel. Does this happen every time? Other information:
Created attachment 93680 [details] ali.zip with correct mime type A small test
Hi Frederik, The root cause of your problem is that the the kernel.org bugzilla doesn't pass the correct mime type. Because Epiphany doesn't know what to do with it, instead of the "Save As, Cancel, Open" dialog you'd see otherwise, you get the "Save As, Cancel, Download" dialog. Why do you still see a Download button, you ask. Well the checkbox in the Preference window is to enable/disable automatic download *and* *open*. Not to disable using the Download directory altogether. However you're not the only one who apparently finds this confusing, since this bug is a duplicate. :) (If I understand your problem correctly, that is!) Could you try the patch attached to bug 341666? Thanks! *** This bug has been marked as a duplicate of 341666 ***