Hidden sections breaks page cross-references in text. Using the file https://nextcloud.documentfoundation.org/s/dpnf4tsZLRMW2ic which is the Writer Guide 25.2 . Let's explain the issue: Each chapter in the book has a section named SEC_COPYRIGHT. The section SEC_COPYRIGHT holds the copyright bla-bla-bla and the chapter's table of contents. The section SEC_COPYRIGHT visibility is controlled by a variable named "book". It is the "1" just after the first paragraph of the book just after the cover. When "book eq 1" the chapter section SEC_COPYRIGHT is hidden. When "book" is something else or undefined, the section SEC_COPYRIGHT is shown. This allows us to compile the book by hiding the chapter's copyright and ToC section. The page references are misplaced because of the hidden sections when "book eq 1" To see the issue, search the string "on page". Click on the page number that follows "on page". To verify, change the variable book to "0". The book will show all the sections SEC_COPYRIGHT, the main ToC will show the new entries, and the number of pages will increase to ~550 pages. But now you can click on the reference "on page NNN" and you will land in the right page. Note: The bad cross-references "on page" are exported to PDF as well.
Confirm with Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: e420583fee9f753e7de5a207637fda25e495ac7d CPU threads: 4; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US Calc: threaded set book = 1 search "The Java JDK/JRE is only required for some features" ... "on page 12" click on 12 -> page 10 (should be "on page 10")
This seems to have begun at the below commit in bibisect repository/OS linux-64-7.2. Adding Cc: to Miklos Vajna ; Could you possibly take a look at this one? Thanks 4c23ac508d8873926dd5928b437b01bcd9209678 is the first bad commit commit 4c23ac508d8873926dd5928b437b01bcd9209678 Author: Jenkins Build User <tdf@pollux.tdf> Date: Wed May 19 11:27:25 2021 +0200 source 1dcd3f1b9fc0d888e047e854a20e9ab2e0afd544 115784: sw: fix not needed invalidation of custom field on each keypress | https://gerrit.libreoffice.org/c/core/+/115784
(In reply to raal from comment #1) > set book = 1 > search "The Java JDK/JRE is only required for some features" ... "on page 12" > click on 12 -> page 10 (should be "on page 10") Hmm, is this a typo, did you mean to write "set book = 0"? When I open the document, the "book" variable is set to 1 already, so the sections are hidden. When I search for "The Java JDK/JRE is only required for some features", I end up on page 16, the field says "page 12" will be the target, and if I click on the field, I indeed end up on page 12. So I can't confirm a bug with these steps. Probably I'm missing something. Thanks.
Please set variable book to 1 and look for the string "on page" followed by a page field. Then do Ctrl_+ click to jump to the indicated page number. You will land in a different page. The PDF generated also carries the issue.
Olivier: thanks, I think I see the problem. But now the bug is bisected to a specific commit, so I need to understand exactly what changed in that commit for this document to fix that specific problem. I have some rough idea (the above performance optimization was for visible custom fields with no sections, this is a hidden field with conditional sections), so there should be a possible middle ground to not regress in terms of performance and have your correct page numbers back, but for this we need to clarify what exactly broke here. raal: thanks for the bisect. I'm afraid I don't really see what changed with that commit. Here is what I see, could you please help clarify? To reproduce the problem, I tried: 1) git clone https://bibisect.libreoffice.org/linux-64-7.2.gi 2) git checkout 4c23ac508d8873926dd5928b437b01bcd9209678 (new, bad state) 3) Open Olivier's "a0.odt" from Nextcloud: $ sha1sum orig.odt 18d003222648d4a61a39f5a7b58087fdecc99c41 orig.odt 4) Go to page 2, double-click on the hidden "book" field, see that the value is "1" already (based on the above, I expect it to be 0, so it can be changed to 1). So leave that unchanged. 5) Search for "The Java JDK/JRE is only required for some features", this jumps to page 16. The expanded value of the page field there is empty (expect a good or bad int page number). 6) Double-click on the empty field: jumps to page 12. So there is a problem here, but not the "page number is wrong" problem. Now let's try with the previous commit in the bibisect repo: 1) git checkout 4c23ac508d8873926dd5928b437b01bcd9209678^ (old, good state) 2) Open Olivier's "a0.odt" from Nextcloud 3) Go to page 2, double-click on the hidden "book" field, see that the value is "1" already, so leave that unchanged. 4) Search for "The Java JDK/JRE is only required for some features", this jumps to page 16. The expanded value of the page field there is empty. 5) Double-click on the empty field: jumps to page 12. So there is a problem here, the old/good commit is failing the same way. In summary, could you please add repro steps for the case that works in the old commit and breaks in the new one? Or should we re-classify this as a non-regression bug? FWIW on master, I can reproduce this with a from-scratch document as well, if my conditional section moves a heading between pages 1 and 2, then the page reference field at the document end expands to "2" all the time, even after tools -> update -> update all. I'm not sure if this is a regression or not. Thanks.
Created attachment 199643 [details] Minimal reproducer Minimal reproducer document: changing the value of the variable hides/shows the section -> heading moves between pages 1 and 2, but the field at doc end expands to "2" all the time. This is clearly a problem, but not sure if it's a regression.