Bug 133709 - Page layout/ text flow wrong/different after undo
Summary: Page layout/ text flow wrong/different after undo
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
Hardware: All All
: medium normal
Assignee: Not Assigned
Keywords: bibisected, bisected
Depends on:
Blocks: Anchor-and-Text-Wrap
  Show dependency treegraph
Reported: 2020-06-05 17:49 UTC by Telesto
Modified: 2023-11-01 13:31 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

Example file (90.80 KB, application/vnd.oasis.opendocument.text)
2020-06-05 17:50 UTC, Telesto
Screencast (881.77 KB, video/mp4)
2020-06-05 17:52 UTC, Telesto
Bibisect log (3.19 KB, text/plain)
2020-06-05 17:52 UTC, Telesto

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2020-06-05 17:49:50 UTC
Page layout wrong/different after undo

Steps to Reproduce:
1. Open the attached file in multipage view
2. Drag the image on page 4 to page 3 as seen in the screencast
3. Press Undo

Actual Results:
Layout changes after undo

Expected Results:
Should be the same.

Reproducible: Always

User Profile Reset: No

Additional Info:
Version: (x64)
Build ID: 191288d6a7fb52b31038a21c4e71ee57ffa3bacd
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL
Comment 1 Telesto 2020-06-05 17:50:32 UTC
Created attachment 161663 [details]
Example file
Comment 2 Telesto 2020-06-05 17:52:21 UTC
Created attachment 161665 [details]
Comment 3 Telesto 2020-06-05 17:52:58 UTC
Created attachment 161666 [details]
Bibisect log

Bisected to
author	Justin Luth <justin.luth@collabora.com>	2020-03-31 14:49:13 +0300
committer	Miklos Vajna <vmiklos@collabora.com>	2020-04-03 10:06:18 +0200
commit f497d1dc27b4fee3db1e2228647a00971922eb5f (patch)
tree 7b141274305372600e8e154ecc5926e79af97ed0
parent 0f29d36aa9e6ac7d0914a6e1749c16ecec216904 (diff)
tdf#131707 sw layout try2: ConsiderTextWrap on positioning
rework 7.0 commit 1052acae9a599c54e518c8fc17d6a994d8778757

jmux and I were working on related bugs at the same time.
My patch happened to get committed before his. Since mine
regressed, use jmux's version instead.

This should fix tdf#119748 and tdf#123257
Comment 4 Telesto 2020-06-05 18:02:20 UTC
Adding CC: to Justin Luth

-> Note: bug is still unconfirmed.. but there is quite a QA backlog.. so adding you in advance. Hope you don't mind.
Comment 5 Telesto 2020-06-05 18:10:24 UTC
Added bug 132415 so see also.. has maybe some similarity. For more even more page flow issues; bug 87740. Added a "few" examples recently; not sure if it's helpful though.
Comment 6 Justin L 2020-06-05 18:53:33 UTC
If it is just my call, I'd simply revert and walk away.
@jmux: do you want to take it instead?
Comment 7 Jan-Marek Glogowski 2020-06-05 19:16:47 UTC
Well - this is interesting. If you do an redo and undo after the initial do and undo, it's correct again! Then you get a wrong redo-undo, then a correct redo-undo, going in this four state circle. The initial position is always correct, so it's eventually three states, but the initial position somehow retains some different state.

While I have the understanding of my initial problem, I don't know what is going on here. But something is missing, so every 2nd undo after the redo actually work correct.

I won't have time to fix it currently. I don't know what is worse, the current state or the previous one. Probably QA should decide?
Comment 8 Telesto 2020-06-05 20:09:00 UTC
(In reply to Jan-Marek Glogowski from comment #7)
> I won't have time to fix it currently. I don't know what is worse, the
> current state or the previous one. Probably QA should decide?

Deciding this something like this is deciding between rock and hard place... it fixes obvious problems.. However I personally hate it if undo does something 'unexpected'

However there is no rush.. So lets float it for a while.. and lets see what happens.. And evaluate after 7.0.2
Comment 9 Justin L 2020-06-06 16:00:48 UTC
(In reply to Jan-Marek Glogowski from comment #7)
> I don't know what is worse, the current state or the previous one.
A regression is always worse than a missing fix. Plus, the chances are pretty good that there will be more regressions, since the impacts/fixes from this are all over the place.

revert proposedl here: https://gerrit.libreoffice.org/c/core/+/95651
Comment 10 Telesto 2020-06-07 11:16:27 UTC
(In reply to Justin L from comment #9)
> revert proposedl here: https://gerrit.libreoffice.org/c/core/+/95651

Please leave it in for a while.. until more regressions show up as proof of being really broken. This one alone should be manageable..  

There is nobody "who understands layout and its implications" in advance. Or 'implications of any change).. Everybody is being haunted by past changes :-)

There already so many hours spend on this. And the Jmux wouldn't be out of the loop either; with bug 123257. Which also called a regression

The whole project is based make a change and solve the issues afterwards as far as possible.. 

I don't want my name on a known bad commit -> Do understand that... however revert is always option later on; we need more 'proof'. This bug was more intended as 'heads up'. Not scaring you off..

And it's "me" asking this.. The one who keeps seeing/ reporting regressions..
Comment 11 Timur 2020-06-08 08:41:53 UTC Comment hidden (obsolete)
Comment 12 Telesto 2020-08-19 19:04:02 UTC
Related to bug 132415 comment 8
Don't revert. Didn't encounter anything broken; and I show have seen something by know; I think. So should be (nearly) risk free
Comment 13 QA Administrators 2022-11-10 04:02:45 UTC Comment hidden (obsolete)
Comment 14 Gabor Kelemen (allotropia) 2022-11-17 13:09:12 UTC
Still an issue in

Version: (X86_64) / LibreOffice Community
Build ID: cfc8a8f5d841b3f84d207196153be67da7f60652
CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3
Locale: en-US (hu_HU.UTF-8); UI: en-US
Calc: threaded
Comment 15 Justin L 2023-11-01 13:31:50 UTC
removing "regression" because it was requested to be kept. Plus, it is not really my patch anyway.