Bug 136220 - Long fields lose its part on page end in some cases
Summary: Long fields lose its part on page end in some cases
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.3.0.4 release
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Writer-Header-Footer
  Show dependency treegraph
 
Reported: 2020-08-28 09:58 UTC by Alexander Polkhovskiy
Modified: 2023-07-21 05:08 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Long fields lose part on page end if external text updated (61.38 KB, application/vnd.oasis.opendocument.text)
2020-08-28 09:59 UTC, Alexander Polkhovskiy
Details
Updated example with no external text and hidden stuff (63.45 KB, application/vnd.oasis.opendocument.text)
2020-12-13 03:35 UTC, Alexander Polkhovskiy
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Polkhovskiy 2020-08-28 09:58:08 UTC
Description:
Long field doesn't continue on the next page in some cases.

Steps to Reproduce:
1. Open the attached file.
2. Confirm updating external data links.


Actual Results:
Look at the last field on the first page - it ends with "Long field" and has no continuation on the next page, but actually it is "Long field with many words".

Expected Results:
Field should continue on the second page with "with many words".


Reproducible: Always


User Profile Reset: No



Additional Info:
This bug is related to (workarounds):
1. Updating external text: if you refuse to update external data on opening, the field is shown fine.
2. Frames in footer: if you delete Frame 1 in footer OR change its wrapping to "Through", the field is shown fine.
3. Text is close to the page end: if you change the Title's interval to 1x line (this makes text move a bit upwards), the field is shown fine.

v 6.4.5.2 (x64)
ID: a726b36747cf2001e06b58ad5db1aa3a9a1872d6
Threads: 8; OS: Windows 10.0 Build 18362; Render: GL; VCL: win; 
Locale: ru-RU (ru_RU); Language: ru-RU
Calc: CL
Comment 1 Alexander Polkhovskiy 2020-08-28 09:59:12 UTC
Created attachment 164791 [details]
Long fields lose part on page end if external text updated
Comment 2 Dieter 2020-12-12 13:25:47 UTC
I ccan see the problem, that footer covers part of the text, If you reduce height of the foote to 10,00 mm text is also displayed. The document contains a lot of hidden frames and tables (I culd see that in navigator). I can't assess, if this is a bug or not. But I guess, it's not an issue with update from external file, but a footer issue. Perhaps you can check for similar bugs in bug 48741.
Comment 3 Alexander Polkhovskiy 2020-12-13 03:35:38 UTC
Created attachment 168122 [details]
Updated example with no external text and hidden stuff

(In reply to Dieter from comment #2)
> I ccan see the problem, that footer covers part of the text, If you reduce
> height of the foote to 10,00 mm text is also displayed. The document
> contains a lot of hidden frames and tables (I culd see that in navigator). I
> can't assess, if this is a bug or not. But I guess, it's not an issue with
> update from external file, but a footer issue. Perhaps you can check for
> similar bugs in bug 48741.

Right you are - problem is not in external file.
Correcting the original message:
Steps to Reproduce:
1. Open the attached file.
2. Try to append text on page 2 - part of the field disappears.


Actual Results:
Look at the last field on the first page - it ends with "Long field". When you open the file you you'll see continuation on the next page ("Long field with many words"), but after you append (or delete) some text anywhere the "with many words" part disappears.

Expected Results:
Field should continue on the second page with "with many words" in any case.


Reproducible: Always


User Profile Reset: No


Additional Info:
This bug is related to (workarounds):
1. Frames in footer: if you delete Frame 1 in footer OR change its wrapping to "Through" or "Background", the field is shown fine.
2. Text is close to the page end: if you change the Title's interval to 1x line (this makes text move a bit upwards), the field is shown fine.
Comment 4 Buovjaga 2021-08-31 15:59:22 UTC
(In reply to Alexander Polkhovskiy from comment #3)
> Created attachment 168122 [details]
> Updated example with no external text and hidden stuff
> 
> Right you are - problem is not in external file.
> Correcting the original message:
> Steps to Reproduce:
> 1. Open the attached file.
> 2. Try to append text on page 2 - part of the field disappears.
> 
> 
> Actual Results:
> Look at the last field on the first page - it ends with "Long field". When
> you open the file you you'll see continuation on the next page ("Long field
> with many words"), but after you append (or delete) some text anywhere the
> "with many words" part disappears.

I don't reproduce this. Could you re-test with 7.2?

Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: a866d63e0ac9de4ff7e59b3928f09ec21877bef3
CPU threads: 2; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win
Locale: fi-FI (fi_FI); UI: en-US
Calc: threaded Jumbo
Comment 5 Alexander Polkhovskiy 2021-09-06 18:35:20 UTC
(In reply to Buovjaga from comment #4)
> (In reply to Alexander Polkhovskiy from comment #3)
> > Created attachment 168122 [details]
> > Updated example with no external text and hidden stuff
> > 
> > Right you are - problem is not in external file.
> > Correcting the original message:
> > Steps to Reproduce:
> > 1. Open the attached file.
> > 2. Try to append text on page 2 - part of the field disappears.
> > 
> > 
> > Actual Results:
> > Look at the last field on the first page - it ends with "Long field". When
> > you open the file you you'll see continuation on the next page ("Long field
> > with many words"), but after you append (or delete) some text anywhere the
> > "with many words" part disappears.
> 
> I don't reproduce this. Could you re-test with 7.2?
> 
> Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community
> Build ID: a866d63e0ac9de4ff7e59b3928f09ec21877bef3
> CPU threads: 2; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL:
> win
> Locale: fi-FI (fi_FI); UI: en-US
> Calc: threaded Jumbo

Reproduced in 7.2.1.1
Version: 7.2.1.1 (x64) / LibreOffice Community
Build ID: 3cfc32d9754d2d239bd8ce2941029c12873010c1
CPU threads: 4; OS: Windows 10.0 Build 19041; UI render: Skia/Vulkan; VCL: win
Locale: ru-RU (ru_RU); UI: ru-RU
Calc: CL
Comment 6 QA Administrators 2021-09-07 03:51:00 UTC Comment hidden (obsolete)
Comment 7 Buovjaga 2021-09-14 10:14:23 UTC
Ah, the bad effect is not triggered in all manipulation on page 2. It is more reliable when you do it in the grey text.
Bibisected with linux-64-6.3 to
https://git.libreoffice.org/core/commit/8e3afdb5989d571410350f1d43fcf26492a4eaff
tdf#122878: enable wrap for flys in footer

Patrick doesn't seem to be active at the moment, so not adding him to Cc.
Comment 8 Alexander Polkhovskiy 2022-07-16 22:27:04 UTC
The problem doesn't appear in 
Version: 7.3.4.2 (x86) / LibreOffice Community
Build ID: 728fec16bd5f605073805c3c9e7c4212a0120dc5
CPU threads: 20; OS: Windows 10.0 Build 19044; UI render: Skia/Vulkan; VCL: win
Locale: ru-RU (ru_RU); UI: ru-RU
Calc: CL

But now it freezes when the footer is shown in the second example (Updated example).