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
Created attachment 151984 [details] Example file
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
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.
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
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?
(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
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:
Adding Cc: to Michael Stahl
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
Dear Michael Stahl, This bug has been in ASSIGNED status for more than 3 months without any activity. Resetting it to NEW. Please assign it back to yourself if you're still working on this.
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.