Description: I have an .odt document which suddenly started inserting thousands of blank new pages. The document should have a few dozen pages, but now it has over 5000. Opening it in Writer causes more pages to be added. Tested on Windows 10 with 7.3.?.? and on Linux with 7.3.5.2. On Windows the the page counter keeps spinning, on Linux the window just freezes when opening the document. The document doesn't have any macros, it looks very much like a layout loop issue, which has been fixed in the past. I don't know which exact change in the document caused the issue, it didn't happen to me. The broken document is attached. I've removed all images from `Pictures` inner directory, so it may look off, but it still breaks Writer. Steps to Reproduce: 1. Open the document Actual Results: Writer freezes in a pages adding loop. Expected Results: Writer doesn't freeze in a pages adding loop. Reproducible: Always User Profile Reset: No Additional Info: It is pain.
Created attachment 181651 [details] The indefinite pages document
As a side note, the document can be opened in OnlyOffice (incomplete, OnlyOffice doesn't support all the necessary features). Even after after it's edited and saved, LibreOffice still falls into the loop.
I've managed to boil down the whole issue to a single-page document. I've added a new attachment with a minimal bug reproduction, it has gutted "Pictures" too. It turns out that one of the images is anchored "as character", but it's a little larger than the page. Its line contains some spaces after the image, which end up outside of the page. This is too much for Writer, it keeps adding new pages and the text keeps being out of the page boundaries.
Created attachment 181654 [details] The minimal reproduction of the indefinite pages document
Works fine using Version: 6.2.0.3 (x64) Build ID: 98c6a8a1c6c7b144ce3cc729e34964b47ce25d62 CPU threads: 12; OS: Windows 10.0; UI render: GL; VCL: win; Locale: ru-RU (ru_RU); UI-Language: en-US Calc: CL Fails (basically, hangs) using Version: 6.3.0.4 (x64) Build ID: 057fc023c990d676a43019934386b85b21a9ee99 CPU threads: 12; OS: Windows 10.0; UI render: GL; VCL: win; Locale: ru-RU (ru_RU); UI-Language: en-US Calc: CL
Regression after commit 7ed962571df02d1d7b286e7af534fadd717a8003 Author Patrick Jaap <patrick.jaap@tu-dresden.de> Date Wed Jan 23 10:01:36 2019 +0100 tdf#122878: enable wrap for flys in footer Possible duplicate of tdf#149424
See also: bug 127235, which was very similar, also caused by a very large object, started after the same commit; and 37b79c872b2637912c5d6972812ee2c9d5b096c7 that fixed it.
(In reply to Mike Kaganski from comment #7) ... but in this case, the check in SwTextFly::ForEach returns false, because page height is 16838 twips, and fly height is 15511 twips ... I have no idea how to approach this. From the logic PoV, we should check if this is in text body; if this is anchored as character (and thus, its top is necessarily inside the text body); if the object height is larger than page body height (i.e., without margins and header/footer) ... and what about footnotes? Miklos: could you please take a look when you have time? Thanks.
Created attachment 181659 [details] A prepared sample: just change the text box wrap to "Parallel" This is only nominally a regression: this same layout loop may be easily reproduced in older versions, just if you anchor your fly frame to a header's paragraph, instead of footer's; you don't even need a large image object anchored as character - simply using a large font size in the text body is enough. The attachment is created from scratch like this: 1. Set font size to 500 pt; 2. Type "A"; 3. Add a header; 4. While in header, create a text box with text "TextBox in header" (make sure you create it over the header area, or else it may be anchored elsewhere), set its border to solid line for visibility; 5. Move the text box over ~center of the page area. This is almost ready to create infinite loop in any LO version, including 3.3.0, and even OOo 2.2.0. The remaining step is: 6. Select the text box (use "Select" arrow tool on Drawing toolbar, and "draw" a selection frame around the text box), and set its Wrap to "Parallel". It didn't happen with footer-anchored objects because of the explicit exclusions changed in the "regression" commit, but it really doesn't matter to properly fix it. It seems that maybe we should not move lines that are first on page, when the reason is something in footer/header (and thus would repeat)? How to detect that constellation?