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

Revision history for this message
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
Revision history for this message
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.

Revision history for this message
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
Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
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

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
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 ?

Revision history for this message
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

Revision history for this message
Franck (alci) wrote :

Bug still not resolved in Intrepid.

Why not use gnome-open as suggested by Mattj ?

Revision history for this message
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():

Revision history for this message
WillerZ (willerz+launchpad) wrote :

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

Revision history for this message
Daeng Bo (daengbo) wrote : Re: [Bug 113092] Re: nautilus in feisty can't open http:// URI which affects service-discovery-applet

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

Dan

Revision history for this message
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 :)

Revision history for this message
WillerZ (willerz+launchpad) wrote :

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

Revision history for this message
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
Revision history for this message
Sebastien Bacher (seb128) wrote :

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

Changed in gnome-vfs:
status: New → Invalid
Revision history for this message
Pablo Saavedra (pablo-a-saavedra) wrote :

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.

Revision history for this message
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.

Revision history for this message
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

Revision history for this message
Pablo Saavedra (pablo-a-saavedra) wrote :

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