Bug 169158 - vertically-centered frame content becomes top-aligned when opening saved document
Summary: vertically-centered frame content becomes top-aligned when opening saved docu...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Mike Kaganski
URL:
Whiteboard: target:26.2.0 target:25.8.4
Keywords: bibisected, bisected, regression
Depends on:
Blocks:
 
Reported: 2025-10-30 16:19 UTC by S. Christian Collins
Modified: 2025-11-05 18:59 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
document that exhibits the bug (10.58 KB, application/vnd.oasis.opendocument.text)
2025-10-30 16:20 UTC, S. Christian Collins
Details
Minimal reproducer (1.93 KB, application/vnd.oasis.opendocument.text)
2025-11-01 08:40 UTC, Mike Kaganski
Details

Note You need to log in before you can comment on or make changes to this bug.
Description S. Christian Collins 2025-10-30 16:19:20 UTC
Description:
I have a document with three frames, all with vertically-centered content. After typing text into these frames and saving, the frames appear top-aligned when the document is re-opened. Attempting to re-edit a frame will cause the alignment to correct back to vertically-centered, which may or may not correctly save.

Steps to Reproduce:
1. Open the attached document in Writer.
2. Type some text into each of the three frames, which should appear vertically centered within the frame.
3. Save and re-open the document.

Actual Results:
The text in each frame is now aligned to the top of the frame.

Expected Results:
The text should still be vertically centered.


Reproducible: Always


User Profile Reset: No

Additional Info:
This bug does not happen in LibreOffice 24.2.7.2 (system version available in the latest Ubuntu LTS), so it appears to be a regression.
Comment 1 S. Christian Collins 2025-10-30 16:20:06 UTC
Created attachment 203626 [details]
document that exhibits the bug
Comment 2 S. Christian Collins 2025-10-30 16:24:05 UTC
I should mention that the bug also happens in LO 25.2.6.2, if that helps with regression tracking. I have repro'd this bug on multiple LO installations across both Fedora 42 KDE and Kubuntu 24.04 LTS.
Comment 3 raal 2025-10-30 18:28:17 UTC
I can confirm with Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: c7b3ea692f293346fbbdf2a391d9d971c34fa1f2
CPU threads: 4; OS: Linux 6.8; UI render: default; VCL: gtk3
Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US
Calc: threaded
Comment 4 S. Christian Collins 2025-10-31 06:30:06 UTC
I did a git binary bisect, which identified the following commit as the culprit:

commit c36ac74ea0ebd5fe4460e4cccf6b2ea38ea11550 (HEAD)
Author: Norbert Thiebaud <nthiebaud@gmail.com>
Date:   Sat Jun 7 03:16:02 2025 -0700

    source b6bcc7ac278e0db22df02707789730ec123bf934

    source b6bcc7ac278e0db22df02707789730ec123bf934

 instdir/program/setup.ini   |   2 +-
 instdir/program/swlo.dll    | Bin 18226176 -> 18225664 bytes
 instdir/program/version.ini |   2 +-
 3 files changed, 2 insertions(+), 2 deletions(-)
Comment 5 raal 2025-10-31 15:11:12 UTC
Adding Cc: to 	Mike Kaganski ; Could you possibly take a look at this one?
Thanks
Comment 6 Mike Kaganski 2025-11-01 08:40:07 UTC
Created attachment 203652 [details]
Minimal reproducer

Not a true regression. There is a pre-existing bug; the minimal reproducer shows it already in OOo 3.2.0. The vertical alignment inside the table is unstable; opening it would paint the content aligned to top, but e.g. moving the mouse over it would *sometimes* fix the drawing; toggling formatting marks may also affect the display.

The reason that makes the original document to paint it correctly initially is the refresh accidentally made when the old code (incorrectly!) assumed there is another page, and then realized there should be none, and re-layouted it. It still shows the problem by toggling the formatting marks in versions prior to the identified commit.
Comment 7 Mike Kaganski 2025-11-01 09:17:01 UTC
FTR: 2bcfb7231b5ca74f02274cfb74ca8463f78905d6 changed behavior wrt. formatting marks display. Before it, showing/hiding paragraph marks didn't change the vertical position of the text (if it was correct in the middle, it stayed in the middle). After that, the position of the text jumps to top every time the function is toggled.

Again, that commit is not causing the problem, it only changes when it manifests. It may possibly turn out to provide a code pointer.
Comment 8 Mike Kaganski 2025-11-02 08:57:25 UTC
https://gerrit.libreoffice.org/c/core/+/193298
Comment 9 Commit Notification 2025-11-02 10:33:01 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/15c89cf1b72a7556af238d9b0a7d34017c6ec3ee

tdf#169158: Call FormatObjsAtFrame again, when at-page fly needs that

It will be available in 26.2.0.

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

Affected users are encouraged to test the fix and report feedback.
Comment 10 Commit Notification 2025-11-05 18:59:43 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "libreoffice-25-8":

https://git.libreoffice.org/core/commit/dcb108323e866fa9cafda685f0de9eb4adb21665

tdf#169158: Call FormatObjsAtFrame again, when at-page fly needs that

It will be available in 25.8.4.

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

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