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

This also happens if you have a bookmark for a stale NFS mount.  I think we
should not check the validity/presence of the bookmarks until you actually try
to activate one.

or - check it asynchronously; clearly it'd be pretty sucky to delay the check
until someone presses the combo box / expands the 'browse to' thing & then still
do it synchronously :-)

Well. It has nothing to do about whether the server responds or not - when you
have enough of bookmarks, it'll be slow no matter how fast your net is, to poke
at each of them.

http://gallery.tigert.com/scratch/bmarks.png 

Most of those are sftp mounts.

All it takes for someone to start _using_ the bookmarks. You will love them, and
you'll add several because they rock. And that is enough to make it too slow to
be useful. Great feature crippled by bad implementation.

Like Michael said, it's silly to poke each mount before showing the dialog.

This is not a problem with only bookmarks, it's in the very design of the
GtkFileChooser/GtkFileSystem. I spent some time looking at this and I seriously
can't see how this can be solved without a serious overhaul of the design.

The problem is that the GtkFileSystem APIs are synchronous by nature, even more
the file chooser uses it in a way that makes it even more synchronous than it
would have to be (by using get_folder to check if a certain URI is a folder).

Fixing this would require new API to the GtkFileSystem interface and a redesign
of how GtkFileChooser uses this API. 

What is surprising me is that no one has thought about this since it's quite
obvious that a synchronous API for remote file systems (existing or not
existing) will never work.

By the way, for reference. The mainloop will also block as soon as you browse a
slow remote file system or try to create a directory on it.

If it's non-existing, the time it will take is left to the GnomeVFS module to
decide when it figures the remote system doesn't exist and gives control back to
the GTK GnomeVFS FileSystem backend that can report the error back to the UI.

Suck. DND from nautilus works on many cases, but it's the saving that sucks
BADLY in this one.

Would it be possible to only check a bookmark when the user tries to open one?
So one would just show the bookmarks in the list, but the fileselector wouldnt
check if they are valid until the user clicked them?

This clearly shows that more developer people should actually start using the
vfs stuff.. Unfortunately many of those mostly use Gnome for the terminal...

This should all be fixable though - right ?

/* This is a "semi-private" header; it is meant only for
 * alternate GtkFileChooser backend modules; no stability guarantees 
 * are made at this point
 */
#ifndef GTK_FILE_SYSTEM_ENABLE_UNSUPPORTED
#error "GtkFileSystem is not supported API for general use"
#endif

Yes, I think it shouldn't be a huge problem getting the needed changes in but
it's a pretty large task to do since you have to fix all the backends and the
filechooser code.

Well, I think we can accept having some kind of blocking on remote dirs coming
from gnomevfs backend.
But the big problem I think is when an user has a remote bookmark. Every
filechooser dialog he get would query the remote host just for adding the
bookmark. Opening a filechooser for reading o saving a local file with a remote
bookmar can be the 90% cases of a 50% scenario of GNOME users, and we should try
to avoid this pain.

Looking at the code in gtkfilechooserdefault, the remote query for a bookmark is
done three times:
1) Check if it is a folder
2) Get the label
3) Get the proper icon

I think we can just skip 1), because only folders can be bookmarked right now,
and the checking then should be done only at creation time
For 2), the code is now using a gtk_file_info_get_display_name over a
GtkFileInfo (that does a remote query). We can try first to do a
gtk_file_system_get_bookmark_label, that in the gnomevfs backend doesn't do a
remote query.
The problem is for 3, that uses gtk_file_system_render_icon, and every
implementation of this uses a fileInfo to get the mime type (with remote query).
Maybe we should add a gtk_file_system_render_bookmark_icon funtion to the
interface, and allow backends to get the icon based only on the path and without
remote query (as gtk_file_system_get_bookmark_label does).

So with this addition I think we will speed up 90% of 50% of normal scenarios :)
 

Fernando, how can blocking the UI be acceptable, no matter if it's a remote
filesystem or not. This problem isn't about bookmarks, it's just happen to
trigger it often.

The biggest issue here is not performance but the fact that if you try to access
a slow or offline remote filesystem it's going to take ages before the UI redraws.

Ubuntu has a similar bug: https://bugzilla.ubuntu.com/show_bug.cgi?id=16286

"if I press "sysrq" to take a screenshot, or if I run "gnome-screenshot" from a
command line, I don't see anything for 30 or 35 seconds.  then the screenshot
window appears.
...
I just "fixed" the problem by going into nautilus and deleting my 2 bookmarks. 
They were both bookmarks to SMB mountpoints within my home directory which
aren't currently mounted.

I have had those bookmarks for a long time now, and they've never caused this
slowdown before, even when the shared drives haven't been mounted.
...
I found a way to reproduce this delay:

In nautilus, make a new bookmark to:

  smb://abc123/abc123/abc123

(where host abc123 doesn't exist).

Then there's a 15 second delay when trying to start gnome-screenshot.

When I first noticed this delay, I had 2 nautilus bookmarks to un-mounted smb
shares, and had a firewall up which prevented them being mounted.  Removing just
one of them halved the delay to 15 seconds.  Taking the firewall down removed
the delay.  But replacing the hostname with a host which doesn't exist brings
the delay back.  If the bookmark is to "smb://abc123/abc123" I see no delay - it
seems I need to add an extra "/abc123" for it to happen."

Mikael, I'm not saying that blocking the UI is acceptable. Only that this
blocking is happening most of time for most of the users under the bookmarks
scenario, and then I should priorize a
"fix/workaround/horrible-hack/not-the-real-fix" for this pain for tons of users
targeted for a 2.12.x release or whatever. Of course we need a full and real fix
for the sync-remote-ops-blocking-the-ui-problem :)
 

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

In the dup in Comment 14, note that also if the URI requires authentication and
your password is not saved in the keyring, you will be asked to authenticate
every time the save dialog is brought up, even if you're not saving to the URI
that requires authentication.  This is just strange, it took me a while to
figure out what was going on, because I forgot I had created a bookmark that
required authentication.  Sometimes you are asked for the password 2-4 times
before it brings up the dialog, if you just hit Cancel (which is strange in
itself, perhaps the file chooser is actually trying more than once to hit the URI).

Also note that some URIs are sometimes available and sometimes unavailable, e.g.
only when a VPN is up.

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

I noticed that the async logic was added to the file chooser recently... but is the file chooser still checking locations before they are accessed?  It used to try connecting to all locations in the shortcuts pane, whether or not they were used in a given save/open operation.

There is a patch in bug 354887 which gets rid of some more touching of remote
filesystems for bookmarks. We still call is_local() for them, though, which
is problematic as well.

Does this still happen in 2.10 with the async code?

(In reply to comment #19)
> Does this still happen in 2.10 with the async code?

I can't reproduce it with GTK+ 2.10.4. I discovered that it would list an empty directory pane, instead of an error (filed as bug 400558).

This was my test case:
1. Setup /etc/exports:
$ cat /etc/exports 
/tmp/   (ro,all_squash,insecure)
2. Start the server:
# service nfs start
3. Mount the share:
# mount localhost:/tmp /mnt/iso/
4. Add the directory to the ~/.gtk-bookmarks
$ echo file:///mnt/iso/ >> ~/.gtk-bookmarks
5. Stop the server to get a stale mount:
# service nfs stop
6. Launch an application and its "Open" dialogue

Works fine. With older versions of GTK+, you'd get a hang by that time...

Thanks for the confirmation :)  Marking as fixed.