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

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

"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.

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.

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.

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.

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

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.

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.

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 ?

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

Bug still not resolved in Intrepid.

Why not use gnome-open as suggested by Mattj ?

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():

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

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 :)

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

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

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

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.

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

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