GNOME Bugzilla – Bug 164404
opening urls from the file selector
Last modified: 2013-07-22 10:08:23 UTC
1. Launch EOG 2. Hit ctrl+o 3. Hit ctrl+l 4. Input a http url You get an error message that looks a lot like EOG is attempting to stat the url up to the file name. when you run eog <url> from the command line, it works perfectly.
I think it is dispalying the correct error message "Saying that the folder contents could not be displayed" because you are opening some location specified in open location. When you run eog <url> from the command line, it works perfectly. Did you mean that eog is opening that url page? I am unable to open that page but a blank eog window(identical to the eog when you launch). Actually this should be reported as a bug because it is not reporting any error.
I mean that typing: eog http://bugzilla.gnome.org/images/gnome-64.png shows a foot logo. but going into eog and attempting to enter it the open location dialog results in the error: error accessing 'http://bugzilla.gnome.org/images': Access denied eog should properly open the url when given it in open location, it should not assume that it is a local directory.
this may be an issue in the gtk file chooser, not in eog itself. For instance try the following experiment: try to open http://bugzilla.gnome.org/images/gnome-64.png in gedit; if you do that from the "Open Location" dialog or from the command line you get a proper error dialog telling you that it's a binary file (since it's an image), but if you try to open it from the ctrl+l dialog of the file chooser you get the access denied dialog
the error dialog comes from gtkfilechooserdefault.c:update_from_entry(), when typing a filepath in the entry the filechooser tries to move to the directory part of the typed path and select the file, but this doesn't work if the user has access to the file but not to the dir the file is in. Reassigning to gtk.
*** Bug 320861 has been marked as a duplicate of this bug. ***
I call eog regression since 2005: for me it doesn't open URIs even from terminal. Anyway, this is a broad bug where the particularly usable use case is that the user would like to open usually some kind of remote file directly. Two other duplicates to this bug are 626080, 652371 (might be others). I don't understand how this bug could linger for so long... it's about one libcurl call! (or similar since you may hate 3rd parties) :P
*** Bug 626080 has been marked as a duplicate of this bug. ***
*** Bug 701408 has been marked as a duplicate of this bug. ***
I am astonished that the bug lasts for so long and is still not fixed. Being able to use remote URLs would have vast advantages for many GTK+ programs. For example I just have the same problem with the "Select a file window" where I would like to select a remote file. So please fix it. Thanks
I second that. Wouldn't it be just to check if the provided string contains the http:// protocol or not and if not look for the local file instead?
Just tested with the latest git gtk+ 3.9 and in Fedora 19 GTK+ 3.8 with the following url and it worked perfectly. URL to image: http://www.gnome.org/wp-content/themes/gnome-grass/images/gnome-logo.png I also tested with the pdf link in bug 626080 and this worked also.
Do you know if this works for HTTPS URLs and URLs that provide authentication info: https://user:pass@hostname:port/path ? Thank you.
Created attachment 249438 [details] The file chooser window does not accept remote files
(In reply to comment #11) > Just tested with the latest git gtk+ 3.9 and in Fedora 19 GTK+ 3.8 with the > following url and it worked perfectly. > > URL to image: > http://www.gnome.org/wp-content/themes/gnome-grass/images/gnome-logo.png > > I also tested with the pdf link in bug 626080 and this worked also. I am using gtk3 3.8.2-1 on Arch Linux and it does not work. I just tried it with the attachment feature in this bug tracker to upload the remote image file. It does not accept the URL to image. See the screenshot in the attachment above.
> I am using gtk3 3.8.2-1 on Arch Linux and it does not work. I just tried it > with the attachment feature in this bug tracker to upload the remote image > file. It does not accept the URL to image. > > See the screenshot in the attachment above. That would be because Firefox sets gtk_file_chooser_set_local_only () which means you can only select files on the local file system. I added a patch recently to allow mounted file systems to be accessed even when this setting is in place as the mounted locations are available locally via FUSE. But what you are trying to do is access the location directly.
(In reply to comment #11) > Just tested with the latest git gtk+ 3.9 and in Fedora 19 GTK+ 3.8 with the > following url and it worked perfectly. > > URL to image: > http://www.gnome.org/wp-content/themes/gnome-grass/images/gnome-logo.png > > I also tested with the pdf link in bug 626080 and this worked also. I am using gtk3 3.8.2-1 on Arch Linux and it does not work. I just tried it with the attachment feature in this bug tracker to upload the remote image file. It does not accept the URL to image. See the screenshot in the attachment. (In reply to comment #15) > > I am using gtk3 3.8.2-1 on Arch Linux and it does not work. I just tried it > > with the attachment feature in this bug tracker to upload the remote image > > file. It does not accept the URL to image. > > > > See the screenshot in the attachment above. > > That would be because Firefox sets gtk_file_chooser_set_local_only () which > means you can only select files on the local file system. I added a patch > recently to allow mounted file systems to be accessed even when this setting is > in place as the mounted locations are available locally via FUSE. But what you > are trying to do is access the location directly. Thanks Timothy. But I am not using Firefox but Chromium. Is there also a patch needed for Chromium?
Mounted locations should now show upin the sidebar in all filechooser dialogs. But as I said if gtk_file_chooser_set_local_only () is set then you will not be able to enter a URI in the location entry box.
(In reply to comment #17) > Mounted locations should now show upin the sidebar in all filechooser dialogs. > But as I said if gtk_file_chooser_set_local_only () is set then you will not be > able to enter a URI in the location entry box. Timothy: Which version of Firefox are you using? I would live to try and see whether it is working on my system and what it takes to allow the same feature in Chromium. Thanks!