Bug#582125: epiphany-browser: "Open" action on the download dialog box does not work

[Jean Privat]

> Works for me. Could you perhaps run epiphany under strace to see if it
> is trying to launch evince (or something else) at all?

OK. It seems it is my fault somewhere.

In the strace I found

---- 8< ----
access("/", F_OK)                       = 0
stat64("/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
access("/openlogo.pdf", F_OK)           = -1 ENOENT (No such file or directory)
lstat64("/home/privat/.gnome2/epiphany/downloads/openlogo(7).pdf",
{st_mode=S_IFREG|0644, st_size=4964, ...}) = 0
lstat64("/openlogo.pdf", 0xffaf7040)    = -1 ENOENT (No such file or directory)
rename("/home/privat/.gnome2/epiphany/downloads/openlogo(7).pdf",
"/openlogo.pdf") = -1 EACCES (Permission denied)
---- 8< ----

The file is downloaded (again?!) in a local directory
/home/privat/.gnome2/epiphany/downloads/openlogo(7).pdf
Then moved to / (that obviously fails).

Why the file is moved do /? Hum... Simply because in my preferences,
the download directory is set to / (I do not remember setting it to /
since it is stupid but whatever).

After configuring the download directory to /home/privat/Download
instead of /. Things now works.

So, in conclusion the bug is gone but there is at least new one.

1- When setting a download directory in the preference panel, the
program should:
 (i) not list the shortcut directories that are non writable (like /);
 (ii) issue a warning, display a confirmation box, or something if the
directory selected with "Other..." is not writable (a warning, not an
error because the directory could become writable later).

2- When downloading a file, the program should:
 (i) not silently ignore the failed renames;
 (ii) propose to save the downloaded file somewhere if the rename
fails (the file was correctly downloaded, it is stupid to ask the user
the change its pref. and re-download again the file).

Do you want I open a new bug or do you prefer renaming this one.

-J