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
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.
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!
Side note, same behavior in the footer (no surprise).
I was unable to find any similar bug reports... so does not look like a duplicate.
(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
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.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.1 or preferably 5.0.2.2 or later) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-10-14
This bug is still present in Libreoffice 5.0.2.2.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.1.6 or 5.2.3 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20161108
This bug is still present in LibreOffice 5.1.6.2 on Fedora 24.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
This bug is still present in LibreOffice 5.3.7.2.
This bug is still present in LibreOffice 6.0.7.3.
Dear Kartik Subbarao, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
This bug is still present in LibreOffice 6.2.8.2.
Repro 7.2+. Discussion is in bug 129302.
Dear Kartik Subbarao, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
This bug is still present in LibreOffice 7.5.2.2
*** Bug 123917 has been marked as a duplicate of this bug. ***
*** Bug 127264 has been marked as a duplicate of this bug. ***
https://gerrit.libreoffice.org/c/core/+/165789
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.
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 :-)
(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!
And indeed, sad that I only noticed your bug now, even several years after you posted to my duplicate :-D
(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!
(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 :-)
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.