Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 70666 - Nautilus displays source of web page insted of page itself
Summary: Nautilus displays source of web page insted of page itself
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: nautilus
Version: 8.0
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Alexander Larsson
QA Contact: Jay Turner
: 68855 73143 75501 75625 82965 (view as bug list)
Depends On:
Blocks: 79579 CambridgeTarget
TreeView+ depends on / blocked
Reported: 2002-08-03 15:55 UTC by Marc Deslauriers
Modified: 2015-01-07 23:58 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2004-10-04 12:26:16 UTC

Attachments (Terms of Use)

Description Marc Deslauriers 2002-08-03 15:55:07 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020724

Description of problem:
When opening a web url in nautilus, it downloads the web page and shows the
source instead of the page

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.Open Nautilus
2.Enter "" in the location bar
3.Look at the source code

Actual Results:  The source code for yahoo's default web page appears

Expected Results:  Well, the web page itself, or if that functionnality is being
removed, a "Nautilus has no viewer for this kind blah blah" type of message I guess.

Additional info:

Comment 1 Sean Dilda 2002-08-05 17:20:58 UTC
This problem also cuases issues for programs such as glade that use nautilus to
display help pages.  You end up seeing the html for the help page instead of the
actual help pages (and the html for those help pages is far from readable).

Comment 2 matteo porta 2002-08-06 21:34:53 UTC
i thought gnome 2 did have a help viewer, specifically written to be light and 
to redhat people: please use it instead of nautilus for viewing help for all 
a unified help system helps :-) linux as a desktop os: i hate clicking on a 
help button and getting loaded nautilus or mozilla or netscape 4 or gnome-help 
or something else! we need only *one* help viewer!

Comment 3 Havoc Pennington 2002-08-07 20:40:46 UTC
Ideally gnome-libs 1 would point at yelp help browser...

Comment 4 Havoc Pennington 2002-08-15 21:23:30 UTC
Nautilus is really annoying me here; I tried setting default text/html handler
to application and htmlview, tried removing TextView as an available component for 
text/html, but it's still falling back to the Text_View listing in text/*

If I have a file foo.html and double-click it, Nautilus opens that in a web
browser; but if I put the full path to foo.html in the location bar, Nautilus
opens it in-place. i.e. essentially if you browse to a file that means display
in-place, not open in an application.

So we need to say "we have no way to display HTML in-place" but that would mean
dropping Text_View out of the text/* handler which in general is not right.

I'm not sure how to go about solving this.

Comment 5 Alexander Larsson 2002-08-16 07:45:33 UTC
Yeah, it's hard. We never managed to decide how to "fix" this for the Gnome 2
release either. 

I guess changing the default to application is a good first step at least.

Comment 6 Elliot Lee 2002-08-28 19:27:03 UTC
*** Bug 68855 has been marked as a duplicate of this bug. ***

Comment 7 Havoc Pennington 2002-08-31 04:00:56 UTC
*** Bug 73143 has been marked as a duplicate of this bug. ***

Comment 8 Havoc Pennington 2002-08-31 04:05:29 UTC
Well this is worse than we thought as URL shortcuts created on the desktop 
(e.g. drag from mozilla) also won't open in a browser.

I'm looking at some hardcoded hack action here.

Comment 9 Havoc Pennington 2002-08-31 06:00:31 UTC
Well, my lame patch didn't work. (I tried always using application instead of
component for text/html, see html-hack patch in nautilus package.)

Maybe never use components for http: uris in desktop files...

Is the ability to say "text/* except text/html" in the new proposed mime spec on it should be ;-)

Comment 10 Havoc Pennington 2002-09-03 05:50:28 UTC
It turns out there are two separate problems.

Problem #1 is a bug in activate_callback in fm-directory-view.c, which is that 
when doing a DISPLAY action on a desktop file with type Link, the "uri" variable 
is e.g., but the "file" variable is e.g.
file:///home/devel/hp/.gnome-desktop/CNN.desktop, and we get the mime type from 
the "file" variable. So we use the viewer for the desktop file's mime type (text
viewer), not the viewer for the web page.

Problem #1 is really hard to fix, because if you try to get the MIME type of the 
link target, we don't yet have the stat() info on the target - it would normally
be retrieved asynchronously. So you have to set up a bunch of asynchronous
handlers to get the MIME type on the remote URI and then activate it.

Fixing Problem #1 would resolve the issue of .desktop files pointing to web
pages working correctly, which is the most important issue in my mind.

Problem #2 is that when you "open location" you always use a view component, 
and never an application. Here arguably if there is no view component, we should 
fall back to an application.

The solution here would factor most of activate_callback from
fm-directory-view.c into a separate function, then call it from
nautilus-window-manage-views.c:determined_initial_window_callback() in the
NO_HANDLER_FOR_TYPE case, instead
of complaining about how there is no viewer available. However the factored-out
activate_uri function would have to be careful not to get into an infinite loop 
as the current activate_callback can end up opening the location.

So any actual solution to this problem is a big old risky code change.

The only quick hack I can think of is:
 - in activate_callback, claim all URIs with http: or https: protocols 
   have type text/html to avoid having to write all the async code
   to get the MIME type of the link target
This is really bad, and probably breaks something, but may be what we have to do.

Alex, what do you think? ;-)

Comment 11 Jonathan Blandford 2002-09-03 06:15:44 UTC
Fixing problem 1 isn't quite right.  The reason we get the URI is so that
start-here:/// and preferences:/// work correctly.  These don't want to be
launched in html-viewer, so we kinda need to consider the URI before we handle
it.  The idea behind 2 was that by handling the URI as put in the location bar
would fix this problem incidentally, as it would try to change to location, fail, and fall back to the browser.  I'm not sure what
weird side effects this would have though.


Might be time for a really bad hack.  Alex?

Comment 12 Alexander Larsson 2002-09-03 06:36:59 UTC
Doing http: munging is dangerous too, because it will probably break webdav
support. There is just no way to know whether a http: uri is a webpage or a
directory/file without doing some i/o.

Comment 13 Alexander Larsson 2002-09-03 06:39:40 UTC
Possible hacky solution for #1 is to do a sync mimetype lookup.
It's not on a fast path anyway.

Comment 14 Alexander Larsson 2002-09-03 07:41:53 UTC
At this point i think this is the only safe thing we can do:

In activation_callback at end:
	/* BADHACK(tm) to make desktop web links work */
	if (nautilus_file_is_nautilus_link (file) &&
	    uri != NULL &&
	    (eel_str_has_prefix (uri, "http:") ||
	     eel_str_has_prefix (uri, "https:"))) {
		gnome_url_show (uri, NULL);
	} else {

This will make links on the desktop work, but not http addresses you type into
the location bar. But it will also not break webdav, or largely change the
behaviour of nautilus. It is also clearly "safe".

Comment 15 Alexander Larsson 2002-09-03 08:39:17 UTC
The badhack is in nautilus 2.0.6-6. Do we consider that enough to close this bug?

Comment 16 Havoc Pennington 2002-09-03 14:49:13 UTC
It's enough to take the bug off the critical path. 
Let's remember to unbreak this for real upstream...

Comment 17 Havoc Pennington 2002-10-01 19:24:41 UTC
Filed two upstream bugs:

Comment 18 Havoc Pennington 2002-10-09 14:51:11 UTC
*** Bug 75501 has been marked as a duplicate of this bug. ***

Comment 19 Havoc Pennington 2002-10-10 15:19:24 UTC
*** Bug 75625 has been marked as a duplicate of this bug. ***

Comment 20 Alexander Larsson 2003-01-29 11:29:50 UTC
*** Bug 82965 has been marked as a duplicate of this bug. ***

Comment 21 Alexander Larsson 2004-10-04 12:26:16 UTC
Shouldn't be a problem in 2.8. We now only use views for folders.

Note You need to log in before you can comment on or make changes to this bug.