nautilus in feisty can't open http:// URI which affects service-discovery-applet

Bug #113092 reported by Joe Clifford on 2007-05-07
56
This bug affects 4 people
Affects Status Importance Assigned to Milestone
GnomeVFS
Invalid
Undecided
Unassigned
service-discovery-applet (Ubuntu)
Low
Unassigned
Nominated for Karmic by Abhishek Dasgupta

Bug Description

Using up-to-date feisty.I am not sure if this is either a bug, regression or removed feature. I am also not sure whether this is a nautilus, gnome-vfs or service-discovery-applet problem. I only discovered this when using service-discovery-applet on my laptop to open web sites published on my home server. Clicking on the Zeroconf published web site from the service-discovery-applet brings up this message:

"Couldn't display http://www.recovermypc.co.uk:80/.
The location is not a folder."

I am almost certain that this function worked perfectly in edgy and that when you clicked on the website in the discovery applet it opened the page in a new tab in firefox.

Other services advertised by the Zeroconf service applet work fine, eg. ssh, vnc etc.

I get the impression that nautilus should be able to handle http:// URIs

I have checked that libgnomevfs2-extra is installed which supplies the libhttp.so module. Also, examining the nautilus service-discovery-applet plugin in /usr/share/service-discovery-applet/plugins/nautilus.py shows that nautilus should be able to open http, https, ftp, ftps, sftp, dav and davs URIs.

Opening a nautilus window, pressing <Ctrl> + L to open a location and typing http://www.domainname.co.uk also brings up the same error about the location not being a folder. The same happens if I run nautilus in a terminal window and also if I use 'File'->'Connect to Server' and then select a custom location (HTTP is not listed).

As a quick fix I changed /usr/share/service-discovery-applet/nautilus.py to run gnome-open instead of nautilus which works for _http._tcp Zeroconf connections but I have no idea if it works for the other protocols listed in the nautilus.py file.

Apologies if this bug is filed under the wrong package.....

Sebastien Bacher (seb128) wrote :

Thank you for your bug, does "gnome-open URL" work correctly? What preferred browser do you use?

Changed in gnome-vfs2:
assignee: nobody → desktop-bugs
importance: Undecided → Low
status: Unconfirmed → Needs Info
Joe Clifford (joeclifford) wrote :

"gnome-open URL" works correctly and opens the URL in a new tab in firefox which is my preferred browser. This works fine for http:// URLs but does not for ftp:// URLs. Using the work-around explained in my initial report where I replaced "nautilus" with "gnome-open" in /usr/share/service-discovery-applet/plugins/nautilus.py allows me to open web sites published via Zeroconf/avahi BUT it breaks the ability to open ftp:// URLs from the service-discovery-applet therefore I am almost sure this is either a nautilus or gnome-vfs bug.

Jacques L. (jacquesl) wrote :

I can confirm this bug. I get exactly the same symptoms described in the second comment.

About ftp urls : gnome-open freezes on them (does'nt do anything but does'nt terminate either), evolution freezes when clicking on an ftp:// links in an email, nautilus can't open ftp folders anymore, etc.
I noticed there was no "ftp" item in /desktop/gnome/url-handlers in gconf, this may be related ...

All this happens on a feisty systems which was upgraded from edgy.

Changed in gnome-vfs2:
status: Needs Info → Confirmed
fredrichl (fredrich-legnemark) wrote :

I can confirm this too, on two laptops and one desktop machine, where i'm attempting to connect via service-discovery-applet to an in-house site on a ubuntu edgy, it used to work but now i get the error message described above.

Now, in my case this isn't that much of a showstopper, since it's only the house Laundry list, but i think it might be more serious if its an corporate intranet or something in that vein, so i think that in the end, it is fairly important.

Basilio Kublik (sourcercito) wrote :

does this still happens?.
I'm in gutsy and manually open with nautilus ftp sites or webdav directories shared via http works fine here, i don't have any url which contains directories published via zeroconf/bonjour, so i'm unable to reproduce this fully.

but it seems that the issue has been addressed and solved.

Simon (simon2) wrote :

Confirm here too (Ubuntu feisty on iBook G4). Whether I try to open a simple webpage (like google.com) or a webdav, I always ge the same error "The location is not a folder".

Simon

Daeng Bo (daengbo) wrote :

My bug was marked as a duplicate, so I'll add the extra info from it that NFS and IPP URIs don't work as expected, either.

MattJ (mwild1) wrote :

Here in Gutsy, it is the first time I tested it though. I modified /usr/share/service-discovery-applet/plugins/nautilus.py to use gnome-open, and it works now (website opens in Epiphany, my default browser). (While I was there I added support for SMB/Samba shares).

I was planning to submit a bug to s-d-a, but found this one. Someone reported that gnome-open doesn't work for FTP? I have only tried HTTP URLs so I don't know.

Franck (alci) wrote :

The bug is still here in Hardy beta, as of 14 apr. 2008.

service-discovery-applet shows me one entry, as :

Web Site > hp LaserJet 2340 [881A7A]

If I select this entry, I get the following error message :

Impossible d'afficher « http://NPI881A7A.local:80/ ».
L'emplacement n'est pas un dossier

(Unable to display « http://NPI881A7A.local:80/ ».
The location is not a forlder)

From a terminal, gnome-open http://NPI881A7A.local:80/ works just fine.
But if I enter the same address in nautilus, I get the very same message as from the applet.
This kind of defeat the purpose of a Just Working zeroconf browser.

I have no other service to test right now, but I guess including MattJ work-around (use gnome-open instead of nautilus) at least for _http._tcp service would be cool to do for Hardy, would'n it ?

Ahmed Osman (ashex) wrote :

This issue is still present in Hardy 8.04.1, will there be a fix for this?

service-discovery-applet:
  Installed: 0.4.4-3
  Candidate: 0.4.4-3
  Version table:
 *** 0.4.4-3 0
        500 http://us.archive.ubuntu.com hardy/universe Packages
        100 /var/lib/dpkg/status

Description: Ubuntu 8.04.1
Release: 8.04

Franck (alci) wrote :

Bug still not resolved in Intrepid.

Why not use gnome-open as suggested by Mattj ?

WillerZ (willerz+launchpad) wrote :

Given that nautilus cannot open http or https URLs I have modified nautilus.py on my box to use firefox for these URLs. I have not modified the other types as I have no way to test them in my network (other than _sftp-ssh._tcp which I can verify DOES work as-is). Patch:

--- nautilus.py 2008-03-12 14:56:20.000000000 +0000
+++ nautilus.py 2008-09-30 20:34:57.000000000 +0100
@@ -28,10 +28,13 @@
         path = get_txt_value(txts,"path")
         username = get_txt_value(txts,"u")
         password = get_txt_value(txts,"p")
+ app = "nautilus"
         if stype == "_http._tcp":
             url = build_url("http",address,port, path, username,password)
+ app = "firefox"
         if stype == "_https._tcp":
             url = build_url("https",address,port, path, username,password)
+ app = "firefox"
         if stype == "_ftp._tcp":
             url = build_url("ftp",address,port, path, username,password)
         if stype == "_ftps._tcp":
@@ -43,7 +46,7 @@
         if stype == "_webdavs._tcp":
             url = build_url("davs",address,port, path, username,password)

- cmdline = ["nautilus", url ]
+ cmdline = [app, url ]
  subprocess.Popen(cmdline).wait()

 def load():

WillerZ (willerz+launchpad) wrote :

Patch formatting (important for Python I think!) got broken above - attaching as a file.

It would be easier just to do
- cmdline = ["nautilus", url ]
+ cmdline = ["xdg-open", url ]
instead of all the conditional stuff.

Dan

Franck (alci) wrote :

Using xdg-open is not only simplier, but also better, as it will use the user's prefered app (Epiphany, abrowser, konqueror, etc...).

This was already suggested using gnome-open, but as I understand it, xdg-open is the freedesktop standard replacement for gnome-open. It was never applied, but I think it should !

+1 for xdg-open for me :)

WillerZ (willerz+launchpad) wrote :

xdg-open works for me; suggest that resolution is adopted.

Sebastien Bacher (seb128) wrote :

reassigning to service-discovery-applet since the change discussed there are for this one

Changed in gnome-vfs2:
assignee: desktop-bugs → nobody
Sebastien Bacher (seb128) wrote :

closing the gnomevfs task that's a service-discovery-applet bug rather

Changed in gnome-vfs:
status: New → Invalid

Anyone knows who's maintaining service-discovery-applet? I'd like this bug to be fixed (I can even do it, it's very simple) and contribute some more plugins.

Ahmed Osman (ashex) wrote :

According to the package the maintainer is Sebastien Bacher. You can submit a patch here as he should get a notification.

Sebastien Bacher (seb128) wrote :

unsubscribing the sponsors, the change is a workaround, if those locations don't work with the default handler that one should be changed rather than not used in a specific software

Actually, I think the plugin should be using a handler that does work. In particular, xdg-open should be used to open arbitrary URLs rather than nautilus IMO

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers