I saw something similar to the details provided in bug 1825. Several times I saw a gray shaded area all along the right side of the page corresponding to the Next link. I have seen occurrences where I could click through the links but could not reverse the path through the same links.

In my previous testing I looked at 3.5.10 and 3.5.13.2. I cannot replicate the problem there.

I can confirm that the width of the handbook page makes a difference. The width of the page also determines whether I see a gray shaded area all long the right side of the page. When the gray shaded area appears then the Next link is dead. The gray shaded area is not required to render the Next link dead.

The khelpcenter window size has no effect. I can change the width of the Contents pane only, which changes the size of the handbook page, which then affects the links.

This all happens in real-time. I do not need to restart khelpcenter.

The only thing certain at my end is there is a difference between before and after commit 6b4be5f. If the cause is not commit 6b4be5f, then commit 6b4be5f exposed Yet Another Latent bug.

The symptoms are similar, but slightly different. For example I haven't seen the gray area and resizing the khelpbook window does make a difference on my system.
Anyhow there is definitely something wrong somewhere.
I have not been able to replicate the problems in other handbooks or other Kicker pages so far. Have you?

> then commit 6b4be5f exposed Yet Another Latent bug.
That's my idea too. Or perhaps some time between Jan 2013 and commit 6b4be5f, a commit introduced a latent bug, which was exposed by commit 6b4be5f.

After I fix bug 1857, I will work on this one.
In the meantime, if you notice any other page which has the same problem, please let me know.

I narrowed the problem to kicker/index.docbook, sect2 id="adding-special-icons".

The problem is with the inline image links.

Part of the problem seems to be the number of icons enabled. There are 9 image links in index.docbook. There seems to be a limit of 3 that can be enabled at any one time. Commenting out the remaining 6 seems to alleviate the bug.

That said, sometimes which images are enabled seems to play a role. I cannot isolate this with repeatability.

The problem is not corrupted files. Substituting the file names makes no difference.

I cannot replicate the problem in 3.5.10 or 3.5.13.2. That implies the problem is related to the khtml->tdehtml renaming. I have no idea whether the problem is css, xslt, or the rendering engine.

(In reply to comment #3)
Thanks for the additional info Darrell.

> I cannot replicate the problem in 3.5.10 or 3.5.13.2. That implies the problem
> is related to the khtml->tdehtml renaming.
Not necessarily, the problem could have been introduced/exposed by another commit as well. I am working on this right now :)

Darrell, as additional info, I created a base system (tqt3 to tdebase) as of Jan 31 2014 and tested on a clean new environment. I still see the same effect/problem.
I wonder what is different between my system and yours, since you didn't have any problem using the package from Feb 6. Confused.

Darrell,
while working on bug 1857, I build a base system up to Dec 22 2013 (as perhaps you have read already).
Using the same base system on a clean environment, I verified again this problem and found exactly the same wrong behavior.
Any chance you could try as well using old packages and narrow down the interval of search? I know you already said Feb 6 2014, but at least on Debian, I could go before that.

The time frame difference between our systems could be explained by the fact that my package sets include patches before the patches are pushed to git. We tested the tdhtml->khtml reversal patches for several days before pushing, but I was applying the patch the moment the patch was available.

Another explanation is I don't have strict rules about time frames. Often I build a full package set and then continue testing and applying additional patches for a few more days. I just push the newer builds into the same package set before I decide to run fresh all over again with a full package set.

That said, my package sets look like this:

Feb. 21-23:     has the bug
Feb. 16-21:     has the bug
Feb: 12-16:     has the bug
Feb. 7:         has the bug
Feb. 6:         no bug
Jan. 29-Feb. 4: has the bug <- Strange! A clue? (Double-checked: has the bug)
Jan. 18-29:     no bug
Jan. 11-16:     no bug
Jan. 5-9:       no bug

Sometimes I wished I created source tarballs and built from them. That would provide a way to diff the sources.

(In reply to comment #7)
Thanks Darrell, that makes this bug even more intriguing.
Actually in my last comment I cheated a little when I said "the same base system on a clean environment" because the environment was not 100% clean, but only "99.9%". I had actually removed all TDE packages from an existing installation (really from a clean environment) and installed the new compiled packages from Dec 22. 
I am now wondering if this made any difference, perhaps in files left over in the user profile. I will do a real 100% clean test and update.

Created attachment 1952 [details]
screenshot dec 22, 2013, clean environment (attachment corrupted)

(In reply to comment #8)
Now this is getting weird and interesting.
I did a real 100% clean install using TDE packages as of Dec 22 2013, run TDE one time, used the default parameters (except for selecting none of the effect in the initial wizard) and checked.
The problem was there already. Moreover I noticed that near some icons, a very large orizontal line is created (see attachment) and words are spread out. There is a long horizontal scroll bar below the page.

So how can I see the problem using sources that are almost two months older than Feb. 6? What is different between Debian and Slackware to explain such a different behavior? Perhaps different building options could be one explanation?

I guess it is not going to be that easy/quick to discover the real reason of this problem

I haven't seen anything like the attached image.

I am not leaning toward differences in distros. I can copy the raw tdebase sources and run meinproc against that and I still get the frozen links.

Comment 3 has the main clues. Something in css, xslt, or rendering seems to not like that handbook page. I will try to find time to create a test docbook file with >3 images.

Comment on attachment 1952 [details]
screenshot dec 22, 2013, clean environment (attachment corrupted)

Can you please resubmit this attachment?  It was corrupted in the Bugzilla upgrade.

Thanks!

Created attachment 1969 [details]
attachment resubmission

>I am not leaning toward differences in distros. I can copy the raw tdebase >sources and run meinproc against that and I still get the frozen links.
>Comment 3 has the main clues. Something in css, xslt, or rendering seems to not >like that handbook page. I will try to find time to create a test docbook file >with >3 images.
I am not so sure about that. If the problem was only in the TDE sources, then we should not see a different behavior between your system and mine, as long as we use the sources from the same day.

I am temporarily setting this bug back to NEW because bug 2016 has a bigger priority for me at the moment. I will come back to this bug at a later stage.

It has been a while since this bug report has been modified, so:
1.) Is this report still valid with the latest GIT sources?
2.) If yes to 1.), does this still block R14 release?
3.) Michele, are you still working on this?

Thanks!

Still valid as of today. To reproduce follow the steps in the original post (you may need to resize the width of the help window to notice the problem).
I haven't work on this bug since my last comment in April, when I set the status back to NEW.
IMO, this is not a major bug and does not cause major loss of usability. If we can fix it before the release of v14.0.0 is good, but if we can't then we shouldn't block v14.0.0.

(In reply to Michele Calgaro from comment #15)
> Still valid as of today. To reproduce follow the steps in the original post
> (you may need to resize the width of the help window to notice the problem).
> I haven't work on this bug since my last comment in April, when I set the
> status back to NEW.
> IMO, this is not a major bug and does not cause major loss of usability. If
> we can fix it before the release of v14.0.0 is good, but if we can't then we
> shouldn't block v14.0.0.

I can reproduce.  It's easiest to just type this URL into the run dialog:
help:/kicker/basics.html

The HTML source looks good so I'm going to guess this is a problem in the HTML tdeioslave, probably in whatever processes the link visibility.

Tim

Created attachment 2277 [details]
Test page

This is actually a nasty bug somewhere in the KHTML renderer.  The attached file is a stripped-down test page; opening it in Konqueror will illustrate the essence of the problem.

Note that the test strings are spaced out with ridiculously large spacing between words flying off the right had side of the page.  This somehow then breaks the link display, but that is irrelevant as KHTML cannot be expected to work properly on such a large broken horizontal canvas.

This has been fixed in GIT hash cc5fd88.

Under certain circumstances (still not exactly sure what they are) the layout engine does not allocate enough space for the text to fit.  When this happened there were two places an unsigned-->signed integer overflow occurred, yielding insanely large values when used again in unsigned integer contexts.

The patch in GIT places error checking in those two places (and fixes a few other minor problems at the same time).  I have neither the patience nor the time to trace the cause of the layout engine allocating insufficient space; as it is this bug took a full day to trace down and fix.  The only effect of that remaining problem is some message spew to the command line (to motivate someone else to fix it ;-)) and a single text character at the end of a line in rare cases partially printing outside of its bounding box (e.g. a table, column, etc.).

Well done Tim!

>I have neither the patience nor the time to trace the cause of the layout 
>engine allocating insufficient space
No problem, I think your fix is more than enough. 
If we detect other instances where the engine allocating problem shows up, we will open a proper bug report at the time and investigate.

Seems fixed here as far as I can tell. Thank you.