Bug 148866 - Strange things happen if chained text meets tables in LO Writer
Summary: Strange things happen if chained text meets tables in LO Writer
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: All All
: medium normal
Assignee: Not Assigned
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Paragraph
  Show dependency treegraph
Reported: 2022-04-30 14:57 UTC by Adalbert Hanßen
Modified: 2023-08-19 19:30 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:

Playground with screenshots to reproduce the bug (366.22 KB, application/vnd.oasis.opendocument.text)
2022-04-30 14:57 UTC, Adalbert Hanßen
Bibisect log (2.88 KB, text/plain)
2022-05-13 20:15 UTC, Telesto

Note You need to log in before you can comment on or make changes to this bug.
Description Adalbert Hanßen 2022-04-30 14:57:48 UTC
Created attachment 179861 [details]
Playground with screenshots to reproduce the bug

I observed this bug in 
Version: / LibreOffice Community
Build ID: f775b625b497b4fa6731bddd433916dde52fbb2e
CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3
Locale: de-DE (de_DE.UTF-8); UI: en-US
Calc: threaded
but it is also present in earlier versions.

I expect that the binding of Format>Paragraph>Indents and Spacings also concatenates with a subsequent table. Otherwise one would risk a widowed table remaining separated from its headline.

If a table is below a headline and if it does not fit to the same page together with it (respecting the table breaking properties of the table: possibly the first part of the table including its own table headline not fitting on the same page), then I expect the headline to move to the next page together with the table.

Sometimes undoing a one keystroke operation does not undo it, you may have to undo one more step and redo it later, in order to return to the old state. I guess there is some <= rather than < (or >= than >) bug in the responsible computations of necessary space. See attached example.
Comment 1 Telesto 2022-04-30 20:08:56 UTC
Also found in
Version: (x64)
Build ID: e75dd1fc992f168f24d66595265a978071cdd277
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win; 
Locale: nl-NL (nl_NL); UI-Language: en-US
Calc: CL

and in
Build ID: c30963b8b4bbbe42a24b97aafa161eff9d7ccdd4
CPU threads: 4; OS: Windows 6.3; UI render: default; 
Locale: nl-NL (nl_NL); Calc: CL

and in
Build ID: aa09fd58bd499a2a2c3a32c5f613892bad54076c
CPU Threads: 4; OS Version: Windows 6.29; UI Render: default; Layout Engine: new; 
Locale: nl-NL (nl_NL); Calc: CL

and in
Build ID: 07ac168c60a517dba0f0d7bc7540f5afa45f0909
CPU Threads: 4; Versie besturingssysteem:Windows 6.2; UI Render: GL; 
Locale: nl-NL (nl_NL); Calc: CL

it's fine with
Versie: (x64)
Build ID: 490fc03b25318460cfc54456516ea2519c11d1aa
Locale: nl-NL (nl_NL)
Comment 2 Telesto 2022-05-13 20:15:12 UTC
Created attachment 180105 [details]
Bibisect log

Bisected to:
author	Tobias Lippert <drtl@fastmail.fm>	2015-09-27 21:30:20 +0200
committer	Oliver Specht <oliver.specht@cib.de>	2015-11-04 14:30:17 +0000
commit 20538f233fe120b33a23d594458d4639b0c9670e (patch)
tree bdb24e0c6c6a10f1bb002ccee8e4eec4e773eccb
parent aa334d55ee34c125f6f4fdfaadbc1ed8fa33f5bc (diff)
tdf#83910 Formatting of lines which consist of a single dummy line only
The document which is attached to the ticket runs into an infinite
loop because GetLineNr() does not increase since
only dummy lines are added during formatting.
Comment 3 Telesto 2022-05-13 20:37:05 UTC
More a long shot from me.. I bibsected this one to Tobias Lippert. I don't think he being around anymore.. 

The reason for the change was a bug 83910 (infinite loop) for DOCX file.. However it breaks do not split paragraphs for some reason.

So the fix might be done at the wrong place.. at least that's my first bold guess .. and well you're the DOCX expert who might know..

Feel free to unCC, if uninterested..