Description: Actual Results: Expected Results: Reproducible: Always User Profile Reset: No Additional Info:
Bug 100477 comment 23 Jan-Marek Glogowski 2018-07-03 14:39:27 UTC This is quite probably the same bug as 113326 and 116872. And this bug is actually old. It was confirmed against 5.0.0.2 in comment 3 and never fixed, just look in the history and read the comments. BTW - 5.0 got the first scheduler patches, long before I tried to fix stuff. Now what is actually happening in all cases: there are "really empty" pages at the end of the document due to whatever reason. If you open the RTF document from 113326 with LO 5.4 and look at the page count in the bottom-left area of the writer status bar, you can see, that the initial document also has 6 pages. But these get reduced to 4, because the last two pages are "really empty". At least I can see this, when opening the document in a remote LO via SSH X forwarding. Reducing always happens, if LO decides it needs to do some layouting, so it happens for the bug 116872 document, if you scroll with the keyboard. "Really empty" means you can't click into these pages via mouse or scroll to them via keyboard, which is an invalid document state AFAIK. So just scroll to these pages via mouse and try to put the cursor in the page. Really the page, not the header or footer! All of my (bi)bisected patches increased the performance of LO job processing. My guess is, something schedules this cleanup job, but this depends on some layouting, which is not finished, when the cleanup job is run. Someone want to debug writer layouting code?