Bug 81012 - FORMATTING: Wrong chapter title in running header/footer after the first page of endnotes
Summary: FORMATTING: Wrong chapter title in running header/footer after the first page...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: Other All
: medium normal
Assignee: Mike Kaganski
URL:
Whiteboard: BSA target:24.8.0 target:24.2.3
Keywords:
: 123917 127264 (view as bug list)
Depends on:
Blocks: Writer-Header-Footer Fields
  Show dependency treegraph
 
Reported: 2014-07-07 18:56 UTC by Kartik Subbarao
Modified: 2024-04-09 08:34 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
zip file containing rh.odt and rh.pdf (44.57 KB, application/zip)
2014-07-07 18:56 UTC, Kartik Subbarao
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kartik Subbarao 2014-07-07 18:56:46 UTC
Created attachment 102388 [details]
zip file containing rh.odt and rh.pdf

Problem description: On the right page header, the Chapter Title field is mis-inserted as the title of the *first* chapter instead of the *current* chapter. This occurs after the first page of endnotes at the end of the section that contains the chapter.

Steps to reproduce:
1. See attached files rh.odt and rh.pdf
2. Note that the chapter title in the header on page 7 is fine (Chapter2), whereas on page 9, it wrongly reverts back to the title of chapter 1 (Introduction)
              
Operating System: All
Version: 4.2.5.2 release
Comment 1 Kartik Subbarao 2014-07-10 15:08:58 UTC
It appears that this bug goes at least as far back as 3.3.0.4. That was the earliest version that I was able to download and test from the download.documentfoundation.org site.
Comment 2 Andrew Pitonyak 2014-07-11 01:56:55 UTC
I was able to reproduce this bug using version 4.2.5.2 on my Fedora Linux system.

The problem appears to be related to the end notes, since, when I make the document longer, the part containing the incorrect field value is only where there are end notes. The irony is that the end notes are from chapter 2 and the pages with the end notes show chapter 1.

I added a third chapter in my copy of the test document, and the point where the end notes begin is properly displays the chapter in which the end notes live, but, after the first page break this is no longer true!
Comment 3 Andrew Pitonyak 2014-07-11 02:02:19 UTC
Side note, same behavior in the footer (no surprise).
Comment 4 Andrew Pitonyak 2014-07-11 02:09:59 UTC Comment hidden (obsolete)
Comment 5 Jorendc 2014-07-16 19:58:35 UTC
(In reply to comment #2)
> I was able to reproduce this bug using version 4.2.5.2 on my Fedora Linux
> system.

Lets mark it as NEW then :-)

Kind regards,
Joren
Comment 6 Kartik Subbarao 2014-09-26 22:59:12 UTC
Looking at the source code and walking through it with gdb, here's what I think is causing the problem.

The Chapter Name field in the header of a page is determined by looking at the first text node in the body of that page. The Index of that text node (returned via the GetIndex() function) is compared to the Index of all of the Chapter Headings (as stored in the Outline array). The chapter with the closest Index value lower than the text node is chosen (by SwNode::FindOutlineNodeOfLevel() in node.cxx). For example, let's say that the heading for chapter 1 has an Index of 22, the heading for chapter 2 is 25, the heading for chapter 3 is 50, and the first text node on our page of interest is 45. Since chapter 2 has the closest index value lower than the text node, its name goes into the header.

Usually, this logic works fine. From what I can tell, the Index value generally correlates to parsing sequence. The Index value for a chapter heading is normally lower than the Index value for the text nodes in that chapter, since the heading is parsed first. However, endnotes seem to be an exception to this. In a document that I tested with chapter 1 and 2 having the above index values, the first endnote of chapter 2 has an Index of 4, and the second endnote has an Index of 7.

This is what causes the problem. When endnote 2 appears as the first text node on a page, its Index value of 7 is below the chapter 2 heading Index of 25, so that page is not seen as being part of chapter 2.

Now, why does the name for Chapter 1 show up as the header on our page of interest? After all, the endnote Index value of 7 is also less than chapter 1's Index value of 22, and should be rejected by some sanity check. It turns out that there is such a sanity check (lines 783-784 of node.cxx), but that sanity check uses a *different* comparison metric. Instead of using the Index value returned by GetIndex(), it uses the result of the Top() function in the page frame, which is the absolute Y value. Endnote 2 of chapter 2 reports a much higher Y value than the heading of chapter 1, so the sanity check passes this and chapter 1's name ends up going into the header.

I don't know what the best fix is to this problem, but I can suggest some things to consider.

1) SwNode::FindOutlineNodeOfLevel() currently uses two different metrics to compare nodes -- Index value and absolute Y value. Would it be better to standardize on just one of these metrics? On the surface, it looks like standardizing on the absolute Y value to fix the bug might require less work overall, but I don't know the code well enough to say for sure.

2) Alternatively, can/should the Index values of endnotes be updated so that they conform to the assumption that SwOutlineNodes::Seek_Entry is making (i.e., that later nodes have higher values)? From an architectural perspective, it would probably be good to clarify whether this property of Index values is something that other parts of the code can rely on, or whether they should not count on it.
Comment 7 QA Administrators 2015-10-14 19:56:21 UTC Comment hidden (obsolete)
Comment 8 Kartik Subbarao 2015-10-16 23:16:04 UTC Comment hidden (obsolete)
Comment 9 QA Administrators 2016-11-08 11:04:40 UTC Comment hidden (obsolete)
Comment 10 Kartik Subbarao 2016-11-08 16:26:28 UTC Comment hidden (obsolete)
Comment 11 QA Administrators 2017-11-09 07:43:11 UTC Comment hidden (obsolete)
Comment 12 Kartik Subbarao 2017-11-09 14:23:09 UTC Comment hidden (obsolete)
Comment 13 QA Administrators 2018-11-10 03:52:05 UTC Comment hidden (obsolete)
Comment 14 Kartik Subbarao 2018-11-10 17:06:54 UTC Comment hidden (obsolete)
Comment 15 QA Administrators 2019-11-11 03:37:20 UTC Comment hidden (obsolete)
Comment 16 Kartik Subbarao 2019-11-15 20:55:51 UTC
This bug is still present in LibreOffice 6.2.8.2.
Comment 17 Timur 2021-05-12 12:50:21 UTC
Repro 7.2+. Discussion is in bug 129302.
Comment 18 QA Administrators 2023-05-13 03:19:04 UTC Comment hidden (obsolete)
Comment 19 Kartik Subbarao 2023-05-13 15:29:10 UTC
This bug is still present in LibreOffice 7.5.2.2
Comment 20 Mike Kaganski 2024-04-04 07:33:33 UTC
*** Bug 123917 has been marked as a duplicate of this bug. ***
Comment 21 Mike Kaganski 2024-04-04 07:33:44 UTC
*** Bug 127264 has been marked as a duplicate of this bug. ***
Comment 22 Mike Kaganski 2024-04-04 10:17:05 UTC
https://gerrit.libreoffice.org/c/core/+/165789
Comment 23 Commit Notification 2024-04-04 13:12:39 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/746b21760b911860c7ac497f10ab07d60111e867

tdf#81012: avoid content frames in footnotes / endnotes

It will be available in 24.8.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 24 Kartik Subbarao 2024-04-04 13:58:58 UTC
Thanks so much for fixing this Mike! I built libreoffice from the 24.2.2.2 source tarball, applied the patch, and tested with multiple documents. Very cool that it was a one-line fix :-)
Comment 25 Mike Kaganski 2024-04-04 14:01:48 UTC
(In reply to Kartik Subbarao from comment #24)

It was very cool that you analyzed it first. It helped me a lot. I didn't touch it before, because I knew it would need hours of debugging first, which I couldn't afford. With your pointers, it was a breeze - I started there, and arrived to the destination in a matter of half an hour. thanks!
Comment 26 Mike Kaganski 2024-04-04 14:02:48 UTC
And indeed, sad that I only noticed your bug now, even several years after you posted to my duplicate :-D
Comment 27 Kartik Subbarao 2024-04-04 15:24:23 UTC
(In reply to Mike Kaganski from comment #25)
> (In reply to Kartik Subbarao from comment #24)
> 
> It was very cool that you analyzed it first. It helped me a lot. I didn't
> touch it before, because I knew it would need hours of debugging first,
> which I couldn't afford. With your pointers, it was a breeze - I started
> there, and arrived to the destination in a matter of half an hour. thanks!

Awesome, glad to hear that my info helped!
Comment 28 Kartik Subbarao 2024-04-04 15:25:19 UTC
(In reply to Mike Kaganski from comment #26)
> And indeed, sad that I only noticed your bug now, even several years after
> you posted to my duplicate :-D

Heh, what counts is that it's fixed now :-)
Comment 29 Commit Notification 2024-04-09 08:34:29 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "libreoffice-24-2":

https://git.libreoffice.org/core/commit/07a566f87213bd4c9c28b454ab4c4d30146fdaa4

tdf#81012: avoid content frames in footnotes / endnotes

It will be available in 24.2.3.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.