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)
7. Reload -> Back to layout at step 2
Saved layout differs from layout on screen
Should be the same
User Profile Reset: No
Version: 22.214.171.124.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
Created attachment 151984 [details]
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: 126.96.36.199.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
Can't reproduce with
as there is the right page part filled with the tables from the beginning.
Tested Version: 188.8.131.52.alpha1+
Build ID: fc8f44e82de4ebdd50ac5fbb9207cd1a59a927e3 - right part is filled from beginning, but after Enter, save, reload this part is missing like in 6.4
This is super confusing regarding the request to bibisect. The layout on first open and upon changes varies a lot during the version history.
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?
(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.
> 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/184.108.40.206.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
Created attachment 161719 [details]
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)
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:
Adding Cc: to Michael Stahl
The layout is properly rendered after clicking on page 2 since:
author Miklos Vajna <firstname.lastname@example.org> 2019-09-16 21:15:28 +0200
committer Mike Kaganski <email@example.com> 2019-09-17 18:57:09 +0200
commit d5b50e74ee822e1c8402e3044e14799e47907ff8 (patch)
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)