Comment 14 for bug 205773

The problem is actually much more mundane: the sidebar in Nautilus currently does synchronous I/O, which takes a while to complete, and locks the process for the duration. (This is the reason synchronous I/O is forbidden within Nautilus. There's another instance where this can happen when interacting with the pathbar that we haven't resolved yet either).

The "Network" backend can take some time to enumerate "files" due to the smb-browse backend taking a bit of time to enumerate "files", but this should be hidden behind Nautilus' design. There's currently no way to avoid that latency, though there's probably more places we can hide it in the network backend (e.g. by using completely asynchronous I/O there too, but I'm not sure how well that's going to fly with GVFS' threading model, something that needs to be asked of Alex Larsson, who designed GVFS but is currently on leave).

The bug in Nautilus would theoretically manifest and will block on any URI dragged over the places sidebar, but in practice, the local filesystems return their id::filesystem keys so fast that you don't see it happening. gvfsd-network currently doesn't even return this key, which should be an early out, but something else is going on that it's apparently not, I'll try to experiment with adding this key to the backend over the weekend to see if we can't speed things up until we rewrite the DnD code in Nautilus.