Description: Lots of empty pages added on paste since 6.5 Steps to Reproduce: 1. Open the attached file 2. CTRL+A 3. CTRL+C 4. CTRL+N 5. CTRL+V Actual Results: 401 Expected Results: 339 shows the original.. 330 on copy/paste with different versions.. so within acceptable range Reproducible: Always User Profile Reset: No Additional Info: Found in Version: 7.0.0.0.beta1+ (x64) Build ID: 2891e91a513520d68ea2b8c59c14335861a15253 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL not in 6.4
Created attachment 163583 [details] Example file
Please, create a minimal reproducer ( less than 10 pages or so )
Created attachment 164168 [details] Example file A reduced file of 67 pages; 90 after paste
Created attachment 164176 [details] Example file Trimmed down little bit more 23 pages
Created attachment 164177 [details] Bibisect log Bisected to author Michael Stahl <Michael.Stahl@cib.de> 2020-04-02 17:18:37 +0200 committer Michael Stahl <michael.stahl@cib.de> 2020-04-03 17:20:22 +0200 commit 166b5010b402a41b192b1659093a25acf9065fd9 (patch) tree 58a783dfc1800c604979380c121337ada3e5ad6f parent 27aa4b16bf704d0246595750daf57b57ff2577b3 (diff) tdf#130685 sw_redlinehide: fix copying to position following redline In DocumentContentOperationsManager::CopyWithFlyInFly(), first CopyNodes() also creates all layout frames, then SaveRedlEndPosForRestore fixes the end position of all redlines that were moved by CopyNodes() (they were moved not by changing their position but by inserting new nodes before their end position). Of course this means that the layout frames are created with redlines that have only a temporary end position, and then things go wrong when the end positions are adjusted, so add something similar to SwUndoDelete::UndoImpl() to recreate the frames in CopyWithFlyInFly(). This hit the assert: sw/source/core/text/redlnitr.cxx:94: std::unique_ptr<sw::MergedPara> sw::CheckParaRedlineMerge(SwTextFrame&, SwTextNode&, sw::FrameMode): Assertion `pNode != &rTextNode || &pStart->nNode.GetNode() == &rTextNode' failed. (regression from ... sw_redlinehide) https://cgit.freedesktop.org/libreoffice/core/commit/?id=166b5010b402a41b192b1659093a25acf9065fd9
Has something to do with graphic11 .. another developer uncovering the lovely (old) empty page bug related to image anchor. Maybe commit changes the timing a bit, tends to accelerate the (underlying) issue..
(In reply to Telesto from comment #4) > Created attachment 164176 [details] > Example file > > Trimmed down little bit more 23 pages Much appreciated. Thanks a lot!
Confirmed with Version: 7.0.1.2 Build ID: 7cbcfc562f6eb6708b5ff7d7397325de9e764452 CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: en-US (ro_RO.UTF-8); UI: en-US Calc: threaded
Tests were based on comment 4: before: 23 after: 34
Can't reproduce this issue in bibisect-linux-7.1 after https://git.libreoffice.org/core/+/b9ef71476fd70bc13f50ebe80390e0730d1b7afb author Michael Stahl <Michael.Stahl@cib.de> Fri Nov 13 20:52:28 2020 +0100 committer Michael Stahl <michael.stahl@cib.de> Mon Nov 16 16:51:19 2020 +0100 tree de2c044f51addf5a7ccc32f0d3289db919d5b19e parent 094ee3955ee81e1bc631d50cc216cbb17a777839 [diff] tdf#134298 sw: layout: remove left-over page frame without content Number of the inserted pages is 23 like in the original document from comment #4. *** This bug has been marked as a duplicate of bug 134298 ***
Confirm. The same number with Version: 7.2.5.2 / LibreOffice Community Build ID: 499f9727c189e6ef3471021d6132d4c694f357e5 CPU threads: 4; OS: Linux 5.13; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded