Description: Page layout different from expect when scrolling down while pages are still loading/layouting Steps to Reproduce: 1. Open the attached file 2. Multi page 4 (3 or 4 pages on a row) 3. Scroll to bottom; take a look at the layout 4. File -> Reload followed by CTRL+END (fast) or scroll down left click & vertical scrollbar 5. Look at the endresult Alternative 1. Open the attached file in single page view 2. File reload 3. Drag the scroll bar down with left mouse click immediately after opening -> Look at the layout... No issue when using navigator pag 70 or CTRL+END Actual Results: Layout is different depending on scrolling Expected Results: Shouldn't make a difference Reproducible: Always User Profile Reset: No Additional Info: Versie: 6.4.3.2 (x64) Build ID: 747b5d0ebf89f41c860ec2a39efd7cb15b54f2d8 CPU-threads: 4; Besturingssysteem: Windows 6.3 Build 9600; UI-render: GL; VCL: win; Locale: nl-NL (nl_NL); UI-taal: nl-NL Calc: CL
Created attachment 159970 [details] Example file
Created attachment 159972 [details] Example of wrong layout
Created attachment 159973 [details] Possible good layout [Note: PDF export is also affected]
Another way to reproduce 1. Scroll to the bottom 2. On the last page: CTRL+A 3. CTRL+X 4. CTRL+Z 5. Save & reload or 1. Scroll to the bottom 2. On the last page: CTRL+A 3. CTRL+X 4. CTRL+V 5. Save and reload
Also in 3.3.0
The file has 70 pages and I don't have time for puzzles - where is the difference?
(In reply to Buovjaga from comment #6) > The file has 70 pages and I don't have time for puzzles - where is the > difference? Compare the last page.. Easier steps: 1. Open the attached file 2. Scroll to bottom & look at they layout 3. CTRL+A 4. CTRL+X 5. CTRL+Z -> Wait until rendering finishes.. different layout
Also in Version: 6.0.6.0.0+ Build ID: c30963b8b4bbbe42a24b97aafa161eff9d7ccdd4 CPU threads: 4; OS: Windows 6.3; UI render: default; Locale: nl-NL (nl_NL); Calc: CL
@Michael, Only for my understanding. Page rendering on file open is different from say select all undo? Or maybe should put it different, it possible to make file rendering on file open behave the same as CTRL+A/CTRL+Z. Would unify the layout (in this case)
(In reply to Telesto from comment #7) > (In reply to Buovjaga from comment #6) > > The file has 70 pages and I don't have time for puzzles - where is the > > difference? > > Compare the last page.. > > Easier steps: > 1. Open the attached file > 2. Scroll to bottom & look at they layout > 3. CTRL+A > 4. CTRL+X > 5. CTRL+Z -> Wait until rendering finishes.. different layout I see, content flows into the second column after step 5. Arch Linux 64-bit Version: 7.1.0.0.alpha0+ Build ID: e2fe4fde592564d35099ad1e2659ad682dfb77f5 CPU threads: 8; OS: Linux 5.8; UI render: default; VCL: kf5 Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded Built on 25 August 2020
hmm guess it should look the same, but it's likely difficult to fix
(In reply to Michael Stahl (CIB) from comment #11) > hmm guess it should look the same, but it's likely difficult to fix I assume so; it's still surprises me that they layout is the same on file opening most of the time :-). With all those dynamics involved. I'm happy I didn't have to invent or maintain it; looks very hard to me. I predict it's related to layouting footnotes/tables. Somehow the rendering is off after the document is presented on screen. So if someone opens a document, shows up & starts scrolling immediately, there is a change the layout will be different on screen. After save and reload they content can shift. However this holds only true for large documents. Especially including footnotes (and maybe also tables) and quite some layout (headings/columns or whatever)
Dear Telesto, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug