Bug 146862

Can you try again with recent rawhide, and reopen if you still see problems ?
The behaviour of yelp on x86_64 was recently improved by a mozilla rebuild

Created attachment 113575 [details]
a log from a "simple" yelp session

Hm, maybe there is some improvement.  I am not sure about that as I am not
using
that tool too often and my memories may be somewhat vague.

But even the most "trivial" session of yelp generates multiple
complaints and mouse clicks in a "content" panel end up with "does not
exist" alerts for things displayed on a screen - exactly in a manner
described in the original report.

Attempts to read man pages with a help of yelp invariably result in
a very loooong wait.  I have seen occasions when after this wait
a formatted man page eventually showed up but with other ones you can
stare at a blank screen, showing only "Loading..." on a yelp title bar,
and after ten minutes nothing changes.

Created attachment 113576 [details]
a log from a yelp session where attempts to read man pages were made

I should have been clear.  Logs from comment #2 and #3 were done with
yelp-2.9.3-5

I tried few more man pages with yelp and some of them seem to show up on a screen
in a reasonable time.  The one which takes a longer while is 'ImageMagick'.
Another one which looks like that it will never show up is 'col'.

These are not results of any systematic investigation or checking how manpages
are written in detail.  I just clicked on few samples in random and these above
were the first two I attempted to read. :-)

Besides if this is supposed to be a "universal documentation reader" then
a support for an 'info' format is missing.

As far as I can see 'yelp-2.9.3-5' behaves exactly like described in all
comments above on x86 installation too; so this is not something architecture
dependent.  Moreover after selecting for the first time on x86 a "Man Pages"
link I got an alert about "missing section", or something to that extent.
Unfortunately I am unable to reproduce that again but a 'col' manpage does
not show up on x86 either.

Hi,
I'm going to put this on an fc4 tracker bug so that it doesn't get forgotton about.

Are you only seeing this behavior with man pages or do you see it with other
help documents in yelp, also?

> Are you only seeing this behavior ...

Depends what you understand by "this behavior". :-)  The original report
of spurious alerts is still valid and obviously it is not about man pages.
What I added in the last paragraph of comment #2 I observed only with
man pages although I did not carry thorough enough investigations to be sure
that this will not happen elsewhere.  On the first look this makes an
impression that yelp is trying to parse man pages by itself, instead of leaving
that task to tools which spent years doing it, and spectacularly fails.
But this is only a rough guess and it may be totally wrong.

On the second thought I should have possibly open a manpages issue as another
bug instead of tacking it as an aside in another report. Oh, well ...

The case of nonworking man pages is upstream in 
http://bugzilla.gnome.org/show_bug.cgi?id=163404

The problem of nonworking links is upstream in 
http://bugzilla.gnome.org/show_bug.cgi?id=170074
(this one has a patch)

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

This bug should be fixed in tomorrow's rawhide.

Oh, I see.  Problems with manpages were "solved" by dropping that
support entirely.  At least as far as I can find.  Pretty effective
if somewhat radical. :-)

The trouble from the original report indeed looks like not there
anymore.

OTOH starting yelp-2.10.0-1 in a terminal window brings quickly the
folllowing:

I/O warning : failed to load external entity
     "/home/michal/.gnome2/yelp-bookmarks.xbel"

(yelp:10611): GLib-CRITICAL **: g_strrstr_len:
     assertion `haystack != NULL' failed

(yelp:10611): GLib-CRITICAL **: g_strrstr_len:
     assertion `haystack != NULL' failed

Unmatched element: partintro
Unmatched element: partintro

The last two lines seems to a "property" of 'GNOME 2.8 Desktop User
Guide'.  No idea if that document or yelp is really at fault.

A bit of a random mousing around brings other surprises.  For example:
under "Application->Games" one can find 'Klotski' manual and in it a
section which starts with:

Playing GNOME Klotski

    * Section 3.1 - To Start GNOME Klotski
    * Section 3.2 - The main window
    * Section 3.3 - Starting a new game
    * Section 3.4 - Moving blocks

These section titles seem to be links but clicking on those does not
have any visible effect.

Somewhat further in a text, in Section 3.2, one can find the following
sentence

You can drag the blocks around with the mouse as described in Section
3.4 - Moving blocks.

with a tail of that looking again like a link.  Clicking on it does
change a screen position; but not to Section 3.4, as one could naively
expect, but to the top of that page.

Once again - no idea what is truly to blame.

Hi Michal,

Can you file a new bug with the summary "yelp jumps to top when following links
to elsewhere on the current page" and the body containing the part of your
comment that starts with "A bit of a random mousing around..."

This bug is already overloaded with a few separate issues and is already closed,
so it would better to start fresh I think.

Thanks