After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 652371 - GtkFileChooser fails to open document denoted by URL
GtkFileChooser fails to open document denoted by URL
Status: RESOLVED INVALID
Product: gtk+
Classification: Platform
Component: Widget: GtkFileChooser
2.24.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
Federico Mena Quintero
filechooser-easish-fix
Depends on:
Blocks:
 
 
Reported: 2011-06-11 19:43 UTC by Radim Tobolka
Modified: 2015-07-05 04:02 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Radim Tobolka 2011-06-11 19:43:12 UTC
Consider I have a ssh account at sftp enabled server. I have application, that uses GtkFileChooser, such as gedit. I would like to open file from my server.

Case A:
There is no active connection to the server, as per gvfs-mount -l.
I start the program, choose File > Open and type following into address bar:
sftp://server/home/user/file
then hit Open button. The open dialog box stays numb. Neither error dialog pops up,
nor error message is printed to console.

Case B:
Server is mounted as per gvfs-mount -l.
I start the program. Go to File > Open and enter again the full URL
of my document. Open dialog still stays numb. However mount is present in the left-side panel.
If I use mouse to open my document (click mount point and locate and select it), it happens so.

I would expect, that entering URL would either open the document and handle mount process for me, or display some
reasonable error/warning.

I've tried following programs with same results, therefore I assume it's a libgtk+ bug rather than of app:
gedit 2.30.4
evince 2.32.0
file-roller 2.32.2

I'm using libgtk 2.24.4-0 as per dpkg --list.

I haven't mentioned following case, that in my opinion further demonstrates, that bug is in in GtkFileChooser:

There is no active connection to the server, as per gvfs-mount -l.
I start the program with argument sftp://server/home/user/file like this:
gedit sftp://server/home/user/file
Program starts, pops up password dialog. When confirmed, it opens the requested document.
Suddenly, server appears mounted as per gvfs-mount -l.
Comment 1 Liquider 2012-12-07 23:45:32 UTC
Duplicate of bug 164404; we wish to be able to open various URIs directly.
Comment 2 Timothy Arceri 2013-07-12 15:13:21 UTC
This is not a duplicate of bug 164404 as that bug was about accessing files via http which do not have to be mounted first.
Comment 3 Liquider 2013-07-12 15:22:54 UTC
And this bug is about accessing via SFTP. Does SFTP need to be mounted first? Does HTTPS?
In majoritiy opinion, both these bugs are about being able to open various URLs and URIs from the file chooser directly. It's an URI-aware location parser that was missing, not a simple HTTP downloader.
Comment 4 Timothy Arceri 2013-07-13 00:27:20 UTC
After rereading the original report and testing this bug it seems I cannot reproduce this bug.

When the sftp location is not mounted I get the following message:

"The folder contents could not be displayed
The specified location is not mounted"

(In reply to comment #3)
> And this bug is about accessing via SFTP. 

Correct an the other one was about http.

>Does SFTP need to be mounted first?

Currently yes this is the way it works. I would think prompting the user to mount this location is all that remains for this bug to be closed.

> It's an URI-aware location parser that
> was missing, not a simple HTTP downloader.

No this is not true. Filechooser is able to detect these URI's as seen by the error message and the fact that http locations work. Filechooser than uses gvfs to access these locations.
Comment 5 Liquider 2013-07-13 13:51:05 UTC
Excuse my ignorance and thanks for clarifying how it works.
Comment 6 Matthias Clasen 2015-07-05 04:02:45 UTC
> ... I cannot reproduce this bug.

Lets close it then