This is the portion of the bug originally described in 3695 that is important
for PR2.

Currently, hyperlinks do not work when viewing Nautilus help pages.

Note that Mathieu is exploring converting all the documentation to SGML, and
this may repair this problem, at least for the Nautilus case.

The general opinion: Nautilus help *must* work for PR2, hyperlinks in other help
pages are less important for PR2.



------- Additional Comments From eli@eazel.com 2000-10-16 19:10:28 ----

Batch-assigning QA ownership of Help System bugs to John Fleck.



------- Additional Comments From mikef@praxis.etla.net 2000-10-17 15:55:59 ----

Need to sync with mathieu on this.



------- Additional Comments From mathieu@gnome.org 2000-10-17 17:18:10 ----

hmmmm. comments from many people:
	- html help' links never worked in mozilla (did it ever worked in the gtkhtml
component ? I dunno)
	- sgml help' links do not work

for html, accessing directly the help through a file:// uri should work
(although it is yucky).
for sgml, nothing should work

Discussion with ramiro:
	- adding a new uri handler in mozilla (M18) using mozilla framework: this is
beautiful but a week of work.
	- adding specific code in mozilla component to translate those uris between
help:// to file://   -> this should also fix the pb of embedded images.
something like 2/4 hours of work.

Mike, could you paste the result of your discussions with ali here ?



------- Additional Comments From mikef@praxis.etla.net 2000-10-17 17:28:40 ----

Ok, here's what I know from talking to Ali and thinking--

-- Apparently, HTML support with links has never worked, so its not amazing that
we're running into the problem now

-- One aspect of the problem is that the gnome-vfs "help:" scheme module doesn't
support path separators, so reading "help:control-center/foo.html" doesn't work

-- Even if this did work right, Embedded Mozilla cannot load embedded images for
non-HTTP based URL schemes.  (For the document proper, things work OK because
Nautilus reads it from gnome-vfs and stuffs it into Mozilla, but this doesn't
work with images)

-- We can do a cheesy hack like we do for "eazel-services:" where we translate
all URL's going in and out of Mozilla in the Mozilla wrapper component.   We'll
be translating them from "help:" to "file:".  However, this solution really bugs
me:  It was ok as a one-off hack, but now that we're doing it twice we should
think of something better.

I'd really like to figure out how to allow Mozilla use gnome-vfs URI schemes for
all content, including embedded images.

Mike



------- Additional Comments From jfleck@inkstain.net 2000-10-19 18:54:01 ----

*** Bug 43840 has been marked as a duplicate of this bug. ***



------- Additional Comments From mikef@praxis.etla.net 2000-10-20 19:55:20 ----

This bug has been refined now.

Only hyperlinks with fragment identifiers (eg #section) don't work.  Example:
the first link in control-center.




------- Additional Comments From jfleck@inkstain.net 2000-10-21 07:45:41 ----

There are two separate things that need to work here.
What Mike has described in the control-center document is a link to an anchor in
a static html page. This is necessary for backwards compatibility - in the past,
docs were shipped with static html pages. Thus a link in gnomecc docs link
"intro.html#GNOMECC-INTRO" must take you to that anchor in the page. We assume
there will still be lots of these on people's machines.

The second involves links within dynamically generated documents, generated on
the fly by gnome-db2html2. These will be of the form
"gnome-help:/prefix/share/gnome/help/nautilus/C/nautilus.sgml?intro", which will
make a call to gnome-db2html2 and generate the appropriate page from within the
Nautilus (or other app's) doc. Mathieu now has a working set of nautilus.sgml
files on which this can be tested. Unfortunately, none of the other GNOME
packages install sgml yet, but I can provide other working sgml files for other
apps if you want to install them yourself for testing.



------- Additional Comments From jfleck@inkstain.net 2000-10-21 13:52:25 ----

OK. I retract that last comment. :)
I finally got through my weekly Nautilus rebuild, and the links *do* now work in
the sgml documents.
Good work, whoever did whatever they did to make this work.




------- Additional Comments From sullivan@eazel.com 2000-10-23 09:44:44 ----

I think this is fixed now? But see bug 43949.



------- Additional Comments From mikef@praxis.etla.net 2000-10-23 14:19:29 ----

I updated the comment to reflect what I see as the current bug.  General
hyperlinks do appear to work.

Also, note that embedded images do not work either, although I can't find any
example of these except in the old Nautilus help pages, so I don't know if
that's an important issue to resolve.

Incidentally, the fix that caused this to work was a memory-corruption issue
Mathieu found in gnome-vfs URL handling.

I've also seen wierd behavour where clicking on a link in a help: document
causes the location text box to display the full file: path to the target
document, rather than maintaining help:






------- Additional Comments From jfleck@inkstain.net 2000-10-23 14:33:00 ----

Re: mfleming's comments about images, there is a separate bug filed on this: 
#3938



------- Additional Comments From sullivan@eazel.com 2000-10-23 15:08:50 ----

Is the remaining issue here the same as bug 42787? The terminology isn't clear to
me, but I think these two bugs (and 3864, which is a specific case of this
issue) are all the same. I'll let someone else decide this for sure.



------- Additional Comments From ramiro@fateware.com 2000-10-26 15:16:36 ----

sullivan: yes

I just heard from Mozilla folks that #fragments (anchors) are broken in Mozilla
M18.  So its out of our hands.

Marking dup of 2787.

*** This bug has been marked as a duplicate of 42787 ***



------- Additional Comments From jfleck@inkstain.net 2000-12-11 08:01:09 ----

I'm marking this "verified," meaning it *is* in fact a duplicate of bug #42787.




------- Bug moved to this database by unknown@bugzilla.gnome.org 2001-09-09 20:41 -------