Bug 125749 - Layout on file open is different compared to the saved state
Summary: Layout on file open is different compared to the saved state
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.4.0.0.alpha1+
Hardware: All All
: medium normal
Assignee: Michael Stahl (allotropia)
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Writer-Tables
  Show dependency treegraph
 
Reported: 2019-06-06 14:49 UTC by Telesto
Modified: 2023-11-04 17:05 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Example file (16.25 KB, application/vnd.oasis.opendocument.text)
2019-06-06 14:50 UTC, Telesto
Details
My result after step 7 (62.20 KB, application/pdf)
2019-06-07 15:45 UTC, Dieter
Details
Bibisect log (2.90 KB, text/plain)
2020-06-07 11:27 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2019-06-06 14:49:53 UTC
Description:
Layout on file open is different compared to the saved state

Steps to Reproduce:
1. Open the attached file
2. Notice the right section the empty
3. Press Enter once (at the top of the page)
4. Right section gets filled
5. Optional: Press CTRL+Z (still same layout as in step 4)
6. CTRL+S
7. Reload -> Back to layout at step 2

Actual Results:
Saved layout differs from layout on screen

Expected Results:
Should be the same


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 6.4.0.0.alpha0+ (x86)
Build ID: ac14e5613597e7361ce6995dacb1bb5bd55b6b00
CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; 
TinderBox: Win-x86@42, Branch:master, Time: 2019-06-06_05:09:49
Locale: it-IT (nl_NL); UI-Language: en-US
Calc: threaded
Comment 1 Telesto 2019-06-06 14:50:07 UTC
Created attachment 151984 [details]
Example file
Comment 2 Dieter 2019-06-07 15:45:48 UTC
Created attachment 152031 [details]
My result after step 7

Layout on file open is different compared to the saved state, but not the same as after step 2

But with regard to the bug summary I confirm the bug with

Version: 6.3.0.0.beta1 (x64)
Build ID: a187af327633f5f00363be5131bd21a13e0f1a7b
CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; 
Locale: en-US (de_DE); UI-Language: en-GB
Calc: threaded
Comment 3 Thomas Lendo 2019-06-09 01:34:03 UTC
Can't reproduce with
LibreOffice 3.3.0 
OOO330m19 (Build:6)
tag libreoffice-3.3.0.4
as there is the right page part filled with the tables from the beginning.
Comment 4 raal 2019-07-29 04:40:28 UTC
Tested Version: 4.2.0.0.alpha1+
Build ID: fc8f44e82de4ebdd50ac5fbb9207cd1a59a927e3 - right part is filled from beginning, but after Enter, save, reload this part is missing like in 6.4
Comment 5 Buovjaga 2020-06-06 14:56:48 UTC
This is super confusing regarding the request to bibisect. The layout on first open and upon changes varies a lot during the version history.

Telesto:
Which version was this file created in?
Was it created by you?
Did you create it intentionally to have an empty right column on the first page? The empty right column is the correct, desired result?
Comment 6 Telesto 2020-06-06 20:58:39 UTC
(In reply to Buovjaga from comment #5)
> This is super confusing regarding the request to bibisect. The layout on
> first open and upon changes varies a lot during the version history.
> 
> Telesto:
> Which version was this file created in?
> Was it created by you?
> Did you create it intentionally to have an empty right column on the first
> page? The empty right column is the correct, desired result?

* By me, based in the content (no memory's of it creating it). 
* Written by LibreOfficeDev/6.4.0.0.alpha0$Windows_x86 on 2019-06-06T16:43:20.235000000 (based on meta.xml) So I assume Build ID: ac14e5613597e7361ce6995dacb1bb5bd55b6b00
* All pages should be visible; properly rendered in 6.0/6.1/6.2 (also on 7.1 after clicking on page 2). 
* Target: testing the stability of the table commits of M. Stahl. 

"Broken" since 6.3
Comment 7 Telesto 2020-06-07 11:27:02 UTC
Created attachment 161719 [details]
Bibisect log

Bisected to
author	Michael Stahl <Michael.Stahl@cib.de>	2019-05-08 16:23:25 +0200
committer	Michael Stahl <Michael.Stahl@cib.de>	2019-05-09 10:53:11 +0200
commit cc5916cd314a27b0cc99560ab887480026630a95 (patch)
tree 924f56d1eb105c9e6d71c90cf6291fec6e3f7f60
parent f8b4d371eddd27594d549fb00294c01229a9bd24 (diff)
tdf#124675 sw: fix crash when moving SwTextFrame in table to prev page
The problem is that the SwTabFrame and SwRowFrame that are being
iterated are deleted:
Comment 8 Buovjaga 2020-06-07 12:30:32 UTC
Adding Cc: to Michael Stahl
Comment 9 Telesto 2020-06-07 13:32:57 UTC
The layout is properly rendered after clicking on page 2 since: 

author	Miklos Vajna <vmiklos@collabora.com>	2019-09-16 21:15:28 +0200
committer	Mike Kaganski <mike.kaganski@collabora.com>	2019-09-17 18:57:09 +0200
commit d5b50e74ee822e1c8402e3044e14799e47907ff8 (patch)
tree 1a21d12415edbbb056fb11d9368881a97876b5e4
parent 3fe3588d6743c27c3734b1b4993f5155c15abe98 (diff)
tdf#105330 sw: fix lost cursor on undoing nested table insert
This is a regression from commit e4509eea8fc7c07ddff48edf0d4c015c2663d896 (n#751313 SwCallLink: avoid
redrawing complete rows without nested tables, 2012-04-20), though
manual testing shows that the underlying problem has been addressed in
the meantime, so this can be reverted.

Over time, some poor tests started to depend on the new behavior so
adapt them as necessary:

1) Change back test added in commit 075fc0c0a34875adf2833e5933b4982b9443a373 (testcase for fdo#38414,
2014-03-18) to its original form, that was changed to an export test in
commit 086550313260d9fa45b91dc705b21bb9b51ce0b8 (move round-tripables to
ooxmlexport, 2016-10-07), as the export of that document still results
in data loss of cell content, just happened to pass so far.

2) Explicitly calculate content of text frames in two more tests, which
just hoped that by the time they assert, the layout is ready already
(but now that the missing notification is restored, it happens that the
first pass of the layout doesn't create them; only a later pass, invoked
by Idle, which doesn't run during cppunit tests).

(cherry picked from commit c56bf1479cc71d1a2b0639f6383e90c1f7e3655b)

Conflicts:
	sw/qa/extras/uiwriter/uiwriter2.cxx

https://cgit.freedesktop.org/libreoffice/core/commit/?id=d5b50e74ee822e1c8402e3044e14799e47907ff8
Comment 10 Xisco Faulí 2021-02-09 14:42:46 UTC Comment hidden (obsolete)
Comment 11 Michael Stahl (allotropia) 2023-08-24 11:09:35 UTC
fixed on master


Michael Stahl committed a patch related to this issue.
It has been pushed to "master":

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

tdf#156724 sw: layout: fix tables not splitting due to footnotes differently

It will be available in 24.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.