Bug 164502 - Textbox text is becoming invisible when moved from one page on another
Summary: Textbox text is becoming invisible when moved from one page on another
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.0.0.3 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Anchor-and-Text-Wrap Textbox Regressions-no-off-page-print-drawobj
  Show dependency treegraph
 
Reported: 2024-12-28 11:04 UTC by BogdanB
Modified: 2025-03-13 21:36 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Demo document (10.94 KB, application/vnd.oasis.opendocument.text)
2024-12-28 11:04 UTC, BogdanB
Details
video testing the bug (4.58 MB, video/webm)
2024-12-28 20:01 UTC, BogdanB
Details

Note You need to log in before you can comment on or make changes to this bug.
Description BogdanB 2024-12-28 11:04:08 UTC
Description:
Opne test.odf document. On page 2 is a colored textbox. Click and move it on the first page. It became invisible.

Steps to Reproduce:
See description

Actual Results:
Textbox is there (you can see in the navigator), but the text is not visibile anymore.

Expected Results:
The textbox keeps its properties after moving on a next page.


Reproducible: Always


User Profile Reset: Yes

Additional Info:
Version: 25.2.0.1 (X86_64) / LibreOffice Community
Build ID: ddb2a7ea3a8857aae619555f1a8743e430e146c9
CPU threads: 4; OS: Linux 6.8; UI render: default; VCL: gtk3
Locale: ro-RO (ro_RO.UTF-8); UI: en-US
Calc: threaded
Comment 1 BogdanB 2024-12-28 11:04:29 UTC
Created attachment 198306 [details]
Demo document
Comment 2 BogdanB 2024-12-28 11:06:49 UTC
In Navigator, if I right-click an invisible text box and choose "Edit" for a moment the color became visible again, disappearing after again.
Comment 3 BogdanB 2024-12-28 11:12:15 UTC
Also in
Version: 7.2.3.2 / LibreOffice Community
Build ID: d166454616c1632304285822f9c83ce2e660fd92
CPU threads: 16; OS: Linux 6.8; UI render: default; VCL: gtk3
Locale: ro-RO (ro_RO.UTF-8); UI: en-US
Calc: threaded

The oldest version I could test.
Comment 4 BogdanB 2024-12-28 11:18:16 UTC
I tested with a new textbox, and by default, textboxes are anchored "to paragraph". However, in my case, the textboxes need to remain fixed on the page where I place them, so they are anchored "to page" — if that matters.
Comment 5 BogdanB 2024-12-28 11:21:48 UTC
I also discovered that Cut - Paste on another page is OK. 
Just moving to another page is changing the textbox.

Another thing that I discovered in debug version of LibreOffice, just opening the file I get:
warn:sw.core:5416:5416:sw/source/core/view/vdraw.cxx:245: Trying to move anchor from invalid page - fix layouting
Comment 6 BogdanB 2024-12-28 11:25:47 UTC
I also want to mention another warnings from opening this file. But I am not sure if they are so important or related:

warn:legacy.osl:5771:5771:sw/source/uibase/app/docstyle.cxx:1332: Collection missing!
warn:legacy.osl:5771:5771:sw/source/uibase/app/docstyle.cxx:1326: SwCharFormat missing!
warn:legacy.osl:5771:5771:sw/source/uibase/app/docstyle.cxx:1326: SwCharFormat missing!
warn:sw.core:5771:5771:sw/source/core/unocore/unostyle.cxx:3697: SwXAutoStyleFamily::insertStyle: Unknown property: ParaTabStopDefaultDistance
Comment 7 BogdanB 2024-12-28 11:33:49 UTC
I created a new file with a new textbox and save. And reopen and move the textbox and save as another file. Here is the difference between content.xml:

xmllint --format content1.xml > content1_pretty.xml
xmllint --format content2.xml > content2_pretty.xml
diff content1_pretty.xml content2_pretty.xml
17c17
<       <style:graphic-properties draw:stroke="none" svg:stroke-color="#000000" draw:fill="none" draw:fill-color="#ffffff" fo:min-height="1.411cm" loext:decorative="false" style:run-through="foreground" style:wrap="run-through" style:number-wrapped-paragraphs="no-limit" style:vertical-pos="from-top" style:vertical-rel="paragraph" style:horizontal-pos="from-left" style:horizontal-rel="paragraph"/>
---
>       <style:graphic-properties draw:stroke="none" svg:stroke-color="#000000" draw:fill="none" draw:fill-color="#ffffff" fo:min-height="1.411cm" loext:decorative="false" style:run-through="foreground" style:wrap="run-through" style:number-wrapped-paragraphs="no-limit" style:vertical-pos="from-top" style:vertical-rel="page" style:horizontal-pos="from-left" style:horizontal-rel="page" draw:wrap-influence-on-position="once-concurrent" loext:allow-overlap="true" style:flow-with-text="false"/>
29a30,35
>       <draw:frame text:anchor-type="page" text:anchor-page-number="1" draw:z-index="0" draw:name="Text Frame 1" draw:style-name="gr1" draw:text-style-name="P1" svg:width="3.493cm" svg:height="1.412cm" svg:x="1.431cm" svg:y="33.791cm">
>         <draw:text-box>
>           <text:p>DEMO1</text:p>
>         </draw:text-box>
>       </draw:frame>
>       <text:p text:style-name="Standard"/>
79,85d84
<       <text:p text:style-name="Standard">
<         <draw:frame text:anchor-type="paragraph" draw:z-index="0" draw:name="Text Frame 1" draw:style-name="gr1" draw:text-style-name="P1" svg:width="3.493cm" svg:height="1.412cm" svg:x="0.157cm" svg:y="0.385cm">
<           <draw:text-box>
<             <text:p>DEMO1</text:p>
<           </draw:text-box>
<         </draw:frame>
<       </text:p>
Comment 8 Robert Großkopf 2024-12-28 15:03:45 UTC
Couldn't confirm the bug with

Version: 24.8.4.2 (X86_64) / LibreOffice Community
Build ID: bb3cfa12c7b1bf994ecc5649a80400d06cd71002
CPU threads: 6; OS: Linux 6.4; UI render: default; VCL: kf5 (cairo+xcb)
Locale: de-DE (de_DE.UTF-8); UI: de-DE
Calc: threaded

Might be it is a special gtk3 bug.
Comment 9 BogdanB 2024-12-28 19:59:32 UTC
I repro with
Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 5bd6ef607d68d371b93ad438fb24e2d8fc352b10
CPU threads: 16; OS: Linux 6.8; UI render: default; VCL: x11
Locale: ro-RO (ro_RO.UTF-8); UI: en-US
Calc: threaded
Comment 10 BogdanB 2024-12-28 20:01:33 UTC
Created attachment 198314 [details]
video testing the bug

Video testing the bug with gen
Comment 11 BogdanB 2025-01-03 19:17:39 UTC
(In reply to Robert Großkopf from comment #8)
> Couldn't confirm the bug with
> 
> Version: 24.8.4.2 (X86_64) / LibreOffice Community
> Build ID: bb3cfa12c7b1bf994ecc5649a80400d06cd71002
> CPU threads: 6; OS: Linux 6.4; UI render: default; VCL: kf5 (cairo+xcb)
> Locale: de-DE (de_DE.UTF-8); UI: de-DE
> Calc: threaded
> 
> Might be it is a special gtk3 bug.

Please try again after watching the video from comment 10.
Comment 12 mikhail.machine 2025-01-30 04:51:51 UTC
Couldn't confirm the bug with

Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: a8ec21adf255b70bb6eeb0a1717190df303d8b26
CPU threads: 12; OS: Windows 10 X86_64 (build 19045); UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_FI); UI: en-US
Calc: threaded
Comment 13 BogdanB 2025-01-30 05:39:28 UTC
mikhail.machine, please download the video, in order to see what is happening when testing on my demo document.

It's happening in
Version: 25.2.0.2 (X86_64) / LibreOffice Community
Build ID: 62af784cc06624122f17ee71c7cf13d906cbaed0
CPU threads: 4; OS: Linux 6.8; UI render: default; VCL: gtk3
Locale: ro-RO (ro_RO.UTF-8); UI: en-US
Calc: threaded

Also in
Version: 25.2.0.0.alpha1+ (X86_64) / LibreOffice Community
Build ID: 0f3f3710280d2476425bb86bc2e065e3e7a82952
CPU threads: 4; OS: Linux 6.8; UI render: default; VCL: gtk3
Locale: ro-RO (ro_RO.UTF-8); UI: en-US
Calc: threaded
Comment 14 Robert Großkopf 2025-01-30 08:29:46 UTC
Tested this again.
Created a textbox on second page. Wrote content to the box.
Moved the box to the first page.
Content is still there.

Tested with
Version: 25.2.0.3 (X86_64) / LibreOffice Community
Build ID: e1cf4a87eb02d755bce1a01209907ea5ddc8f069
CPU threads: 6; OS: Linux 6.4; UI render: default; VCL: kf5 (cairo+xcb)
Locale: de-DE (de_DE.UTF-8); UI: de-DE
Calc: threaded
Comment 15 BogdanB 2025-01-30 08:58:04 UTC
(In reply to Robert Großkopf from comment #14)
> Tested this again.
> Created a textbox on second page. Wrote content to the box.
> Moved the box to the first page.
> Content is still there.
> 

For testing with a new file and new text box read this from comment 4:
I tested with a new textbox, and by default, textboxes are anchored "to paragraph". However, in my case, the textboxes need to remain fixed on the page where I place them, so they are anchored "to page" — if that matters.

It is easier anyway to test with the demo document, after watching the video.

I will test now on Windows, to see if I can reproduce
Comment 16 BogdanB 2025-01-30 08:59:06 UTC
With the demo document, I can reproduce on Windows also

Version: 25.2.0.3 (X86_64) / LibreOffice Community
Build ID: e1cf4a87eb02d755bce1a01209907ea5ddc8f069
CPU threads: 4; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win
Locale: ro-RO (en_US); UI: en-US
Calc: threaded
Comment 17 raal 2025-01-31 16:05:42 UTC
Confirm with Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 7cd00ca413da8d29f54749c04493e85937a2fa38
CPU threads: 4; OS: Linux 6.8; UI render: default; VCL: gtk3
Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US
Calc: threaded

No repro with Version 4.1.0.0.alpha0+ (Build ID: 847749e975a7111ea306909a29fddb5df13e9a7)
Comment 18 raal 2025-01-31 16:47:26 UTC
This seems to have begun at the below commit in bibisect repository/OS bibisect-linux-64-5.4.
Adding Cc: to Michael Stahl ; Could you possibly take a look at this one?
Thanks
 57765e5199df63e3def923f259bf5e6352d575c5 is the first bad commit
commit 57765e5199df63e3def923f259bf5e6352d575c5
Author: Jenkins Build User <tdf@pollux.tdf>
Date:   Wed Feb 8 08:29:33 2017 +0100

    source 689cead9e0837dc932e3a4cd765f7d319b529018

https://git.libreoffice.org/core/+/689cead9e0837dc932e3a4cd765f7d319b529018
tdf#91260 svx, sw: don't paint off-page part of drawing object
Comment 19 Gabor Kelemen (allotropia) 2025-03-13 21:36:35 UTC
Regression commit was in 2017, not under warranty anymore:).
Feel free to sell this to anyone.