Download it now!
Bug 118545 - Footnotes randomly lose double spacing
Summary: Footnotes randomly lose double spacing
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.4.0.3 release
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Caolán McNamara
URL:
Whiteboard: target:6.2.0 target:6.1.0.2 target:6.0.7
Keywords: bibisected, bisected, filter:doc, regression
Depends on:
Blocks:
 
Reported: 2018-07-05 09:36 UTC by Donald Haase
Modified: 2018-07-25 16:28 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot of issue (23.08 KB, image/png)
2018-07-05 09:40 UTC, Donald Haase
Details
Screenshot of expected result (23.09 KB, image/png)
2018-07-05 09:42 UTC, Donald Haase
Details
Document exhibiting the issue (409.00 KB, application/msword)
2018-07-16 00:31 UTC, Donald Haase
Details
Screenshot of issue from attached document (28.12 KB, image/png)
2018-07-16 21:49 UTC, Donald Haase
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Donald Haase 2018-07-05 09:36:44 UTC
Description:
While editing a large document, often extremely minor changes will cause footnotes to appear as if they are overlapping, or to lose their formatting (double spacing). By highlighting them and choosing 'Update style' (or by editing and undoing the edit). I've not been able to determine exactly what changes made cause this.

Steps to Reproduce:
1. I have not been able to consistently reproduce the issue.
2.
3.

Actual Results:
Minor changes made in a document cause footnotes to appear with improper formatting.

Expected Results:
Footnote styles should be updated/enforced if they are caused to move by other edits.


Reproducible: Sometimes


User Profile Reset: Yes



Additional Info:
Comment 1 Donald Haase 2018-07-05 09:40:52 UTC
Created attachment 143314 [details]
Screenshot of issue

This is how the error presents. Note 136 has lost its double spacing, being directly above 137. Note 138 has shifted partially out of the range of the page. A second screenshot will demonstrate how they look after selecting each and choosing 'Update style' to reinforce the style rules for footnotes.
Comment 2 Donald Haase 2018-07-05 09:42:58 UTC
Created attachment 143315 [details]
Screenshot of expected result

This is how the footnote should look. There was space at the bottom of the page to accommodate the longer footnote. There is now the appropriate space between 136 and 137. Additionally 138 is no longer cut off.
Comment 3 Buovjaga 2018-07-15 15:52:52 UTC
We need an example document. Hopefully you can produce a minimal example.

Please attach an example document.
Set to NEEDINFO.
Change back to UNCONFIRMED after you have provided the document.
Comment 4 Donald Haase 2018-07-16 00:28:39 UTC
I will attempt to reproduce it in a smaller document. In the meantime I will provide the original, but it is 95 pages with 232 footnotes. I had not seen this occur in earlier versions of the same document that were shorter.
Comment 5 Donald Haase 2018-07-16 00:31:07 UTC
Created attachment 143565 [details]
Document exhibiting the issue

This is the document that exhibited the strange footnote behavior.
Comment 6 Buovjaga 2018-07-16 16:11:43 UTC
Does the style change occur upon saving & reloading or while editing?

I did some edits on page 53 (47), saved & reloaded, but the spacing did not change.

Arch Linux 64-bit
Version: 6.2.0.0.alpha0+
Build ID: 860a9daf2b45942a4b10ff22d36aa3fe29be19f4
CPU threads: 8; OS: Linux 4.17; UI render: default; VCL: gtk3; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group threaded
Built on July 14th 2018

Arch Linux 64-bit
Version: 6.0.5.2
Build ID: 6.0.5-1
CPU threads: 8; OS: Linux 4.17; UI render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Comment 7 Donald Haase 2018-07-16 21:46:19 UTC
Almost invariably on opening the document, at least one footnote will be impacted.

I just tested now opening and closing the document multiple times and see that (at least) footnotes 68, 87, 97 and many more are cut off (same issue as footnote 138 in the previously uploaded screenshot). I'll upload another screenshot to demonstrate.
Comment 8 Donald Haase 2018-07-16 21:49:01 UTC
Created attachment 143584 [details]
Screenshot of issue from attached document

The previous screenshots were from a different revision of the document than the one uploaded for testing.
Comment 9 Buovjaga 2018-07-17 10:04:24 UTC
(In reply to Donald Haase from comment #7)
> Almost invariably on opening the document, at least one footnote will be
> impacted.
> 
> I just tested now opening and closing the document multiple times and see
> that (at least) footnotes 68, 87, 97 and many more are cut off (same issue
> as footnote 138 in the previously uploaded screenshot). I'll upload another
> screenshot to demonstrate.

Thanks. I bibisected with Linux 44max repo against the file opening situation and got this blamed commit: https://cgit.freedesktop.org/libreoffice/core/commit/?id=60d34e1c840d2c317bb7d0a5b14f4602c22b3fcc
coverity#735517 Logically dead code
its possible that this was the original intent, maybe

While testing, I always jumped to page 27 by finding the string deuterocanonical and observed if footnote 68 was cropped.

The code the commit touched has since 2014 seen further renovations, so I skipped trying to revert it to the original state.

Adding Cc: to Caolán McNamara
Comment 10 Caolán McNamara 2018-07-17 15:29:26 UTC
I guess we can put it back to its historic state
Comment 11 Commit Notification 2018-07-17 20:13:21 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=cee296066ab780217395201ab84c2150c8840d25

Resolves: tdf#118545 restore to historic logic

It will be available in 6.2.0.

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

Affected users are encouraged to test the fix and report feedback.
Comment 12 Caolán McNamara 2018-07-17 20:16:12 UTC
backport to 6-1 in gerrit
Comment 13 Xisco Faulí 2018-07-18 16:11:09 UTC
Verified in

Version: 6.2.0.0.alpha0+
Build ID: 95b00f1bfa341003af23e150d316d943d47909cf
CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group threaded

@Caolán, Thanks for fixing this!!
Comment 14 Commit Notification 2018-07-18 16:13:00 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-6-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=7cca3ff7d0c2d1bf6e47fa69c4edb939e51d098c&h=libreoffice-6-1

Resolves: tdf#118545 restore to historic logic

It will be available in 6.1.0.2.

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

Affected users are encouraged to test the fix and report feedback.
Comment 15 Commit Notification 2018-07-25 16:28:18 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-6-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=b26718458b46e23e2d644b1580565d30f3df8871&h=libreoffice-6-0

Resolves: tdf#118545 restore to historic logic

It will be available in 6.0.7.

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

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