Trying to track down the problem, I changed line 1383 in prefs-dialog.c to call gtk_file_chooser_dialog_new rather than ephy_file_chooser_new. The problem no longer occurs when using gtk_file_chooser_dialog_new.

This happens even if the checkbox "Automatically download and open files" is not checked and the "Download folder" combo box is deactivated. (Note that the combo box shouldn't be deactivated because this setting is needed for shift-click/download link). It also effects the third party extension "video downloader" (disclaimer: I'm the developer of this extension).

(In reply to comment #2)
> This happens even if the checkbox "Automatically download and open files" is
> not checked and the "Download folder" combo box is deactivated. (Note that the
> combo box shouldn't be deactivated because this setting is needed for
> shift-click/download link)

IIRC, the XDG download directory is used in the latter case.

(In reply to comment #3)
> (In reply to comment #2)
> > This happens even if the checkbox "Automatically download and open files" is
> > not checked and the "Download folder" combo box is deactivated. (Note that the
> > combo box shouldn't be deactivated because this setting is needed for
> > shift-click/download link)
> 
> IIRC, the XDG download directory is used in the latter case.

Well, guess that is an other bug:

$ cat user-dirs.dirs
[...]
XDG_DOWNLOAD_DIR="$HOME/"
[...]
$ epiphany gnome.org

Then: Open Preferences; set Download folder to "Desktop"; uncheck "Automatically download and open files"; close Preferences; shift-click on link

=> apears on Desktop (tried with different folder, too).

*** Bug 586583 has been marked as a duplicate of this bug. ***

*** Bug 591536 has been marked as a duplicate of this bug. ***

I can reproduce the problem with epiphany 2.26.x, but I can't reproduce this problem with master. Can anyone please try to reproduce with 2.27.x and let us know what happens? Also, what distributions are the people who can reproduce the problem use?

I'm running 2.26.3 on Gentoo x86_64.

(In reply to comment #7)
> I can reproduce the problem with epiphany 2.26.x, but I can't reproduce this
> problem with master. Can anyone please try to reproduce with 2.27.x and let us
> know what happens? 

I can't reproduce with 2.27.90...

*** Bug 597316 has been marked as a duplicate of this bug. ***

I guess the preference dialog code hasn't changed much with the gecko -> webkit transition, maybe bissecting the issue would point to the patch that fixed the issue.

I'm considering this bug fixed now, please feel free to reopen if you can still reproduce it on epiphany 2.28+.

One more thing, this bug is solved in 2.28 simply because the following commit was magically dropped:
http://git.gnome.org/browse/epiphany/commit/?h=gnome-2-26&id=7dbe33b5bfd99ff4ef116f8ccf4777edd8ade788

(except +#include <unistd.h>)

that commit for fixing something related with preventing "hog of any mountpoints" is causing this issue in 2.26 and doesn't cause it in 2.28 because it was not included, is this expected? I mean, would be safe for us downstream to simply drop that commit?

Thanks

Pacho I think it /might/ be related to some gvfs thing or something. Just make sure it doesn't /hog any mountpoint/ and backport it. IMHO.

I meant old gnome-vfs by "some gvfs" (can't really recall what 2.26 used).

If I don't misremember, epiphany 2.26 already uses gvfs because it caused other problems since gecko is still using gnome-vfs, causing unproper apps being opened by default when downloading and opening files (but it was a different problem)

The problem is that I am not a programer, then, I don't know why http://git.gnome.org/browse/epiphany/commit/?h=gnome-2-26&id=7dbe33b5bfd99ff4ef116f8ccf4777edd8ade788 commit breaks 2.26 branch causing download directory to become "/" everytime preferences window is opened :-(

diff --git a/lib/ephy-file-chooser.c b/lib/ephy-file-chooser.c
+++ b/lib/ephy-file-chooser.c
@@ -127,6 +127,8 @@ static void
ephy_file_chooser_init (EphyFileChooser *dialog)
{
dialog->priv = EPHY_FILE_CHOOSER_GET_PRIVATE (dialog);
+
+ gtk_file_chooser_set_current_folder (GTK_FILE_CHOOSER (dialog), g_get_home_dir ());
}

When opening a new file chooser, set the current dir to user's home dir.

+++ b/lib/ephy-file-helpers.c
@@ -261,6 +264,10 @@ ephy_file_helpers_init (const char *profile_dir,
{
const char *uuid;
+ /* Make sure the server process doesn't hog any mountpoints! */
+ if (chdir ("/") < 0)
+ g_warning ("Failed to chdir to /: %s", g_strerror (errno));
+

If you run a program with /some/mountpoint as the current working dir, it will lock that mountpoint until it finishes running. So this is a hack to make the running dir be '/' no matter which was the original.

It's safe to revert in your package as long as you confirm the mountpoint locking is not happening in your build.

(In reply to comment #17)
> +++ b/lib/ephy-file-helpers.c
> @@ -261,6 +264,10 @@ ephy_file_helpers_init (const char *profile_dir,
> {
> const char *uuid;
> + /* Make sure the server process doesn't hog any mountpoints! */
> + if (chdir ("/") < 0)
> + g_warning ("Failed to chdir to /: %s", g_strerror (errno));
> +
> 
> If you run a program with /some/mountpoint as the current working dir, it will
> lock that mountpoint until it finishes running. So this is a hack to make the
> running dir be '/' no matter which was the original.
> 
> It's safe to revert in your package as long as you confirm the mountpoint
> locking is not happening in your build.

Sorry but, how could I check it? I am unable to know what does "run a program with mountpoint as working dir" from epiphany :'-( (I have also been unable of finding a bug reporting that issue for having some thoughts about how could I check it) 

If you don't have time, don't worry, I understand that you probably have more important things to do