Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 70666
Summary: | Nautilus displays source of web page insted of page itself | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Marc Deslauriers <marc.deslauriers> |
Component: | nautilus | Assignee: | Alexander Larsson <alexl> |
Status: | CLOSED RAWHIDE | QA Contact: | Jay Turner <jturner> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 8.0 | CC: | agrajag, alexl, chris.ricker, jrb, keizie, mikemaccana, srevivo, wtogami |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i686 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2004-10-04 12:26:16 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 67218, 79579, 100644 |
Description
Marc Deslauriers
2002-08-03 15:55:07 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). i thought gnome 2 did have a help viewer, specifically written to be light and fast. to redhat people: please use it instead of nautilus for viewing help for all applications! 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! Ideally gnome-libs 1 would point at yelp help browser... 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. 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. *** Bug 68855 has been marked as a duplicate of this bug. *** *** Bug 73143 has been marked as a duplicate of this bug. *** 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. 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 freedesktop.org? it should be ;-) 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. http://www.cnn.com, 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? ;-) 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 http://www.cnn.com/, fail, and fall back to the browser. I'm not sure what weird side effects this would have though. Tricky. Might be time for a really bad hack. Alex? 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. Possible hacky solution for #1 is to do a sync mimetype lookup. It's not on a fast path anyway. 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". The badhack is in nautilus 2.0.6-6. Do we consider that enough to close this bug? It's enough to take the bug off the critical path. Let's remember to unbreak this for real upstream... Filed two upstream bugs: http://bugzilla.gnome.org/show_bug.cgi?id=94627 http://bugzilla.gnome.org/show_bug.cgi?id=94628 *** Bug 75501 has been marked as a duplicate of this bug. *** *** Bug 75625 has been marked as a duplicate of this bug. *** *** Bug 82965 has been marked as a duplicate of this bug. *** Shouldn't be a problem in 2.8. We now only use views for folders. |