https://bugs.documentfoundation.org/show_bug.cgi?id=165472

Miklos Vajna <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |NEEDINFO

--- Comment #5 from Miklos Vajna <[email protected]> ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.

Reply via email to