Description: Floating multipage table rendered (mostly) off-canvas after deleting a row; hiding >30 pages of content Steps to Reproduce: 1. Open attachment 191005 [details] (158344) 2. Look at the page counter (51 pages) 3. Place cursor in the first row of the table on page 1 4. Press Delete Row -> 16 pages left 5. (Bonus) Press CTRL+Z -> 61 pages The table is present but rendered off-canvas Actual Results: Table rendered of canvas Expected Results: Table should be visible Reproducible: Always User Profile Reset: No Additional Info: Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: ff113b34dd6f54765995440cbedd27483fadb844 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 threaded
Alternative 1. Open attachment 191005 [details] 2. Check page count (51 pages on file open) 3. Press Enter 11 times (fine) 4. Press Enter again a couple of times (pages start to vanish) 5. Press CTRL+Z multiple times -> Pages still gone
I can confirm but I get sightly different results regarding the number of pages: (In reply to Telesto from comment #0) > 2. Look at the page counter (51 pages) I start with 18 pages. > 3. Place cursor in the first row of the table on page 1 > 4. Press Delete Row -> 16 pages left I get 9 pages. > 5. (Bonus) Press CTRL+Z -> 61 pages 19 pages. > The table is present but rendered off-canvas This can be confirmed by moving the cursor down with the keyboard in column 2, eventually it navigates into the margin. Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: f42363c51672a5b3685b0b9b11e932680530dce3 CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: CL threaded Miklos, what do you think?
Sure, it's valid to expect that row delete + undo results in the same page count as the original one.
I just wanted to mention the attached file results in a crash rather than open up the attachment.
(In reply to wjsim from comment #4) > I just wanted to mention the attached file results in a crash rather than > open up the attachment. Which version? You might be seeing bug 158344, which is already fixed, so please test with a recent daily build: https://dev-builds.libreoffice.org/daily/master/current.html
(In reply to Stéphane Guillou (stragu) from comment #5) > (In reply to wjsim from comment #4) > > I just wanted to mention the attached file results in a crash rather than > > open up the attachment. > Which version? You might be seeing bug 158344, which is already fixed, so > please test with a recent daily build: > https://dev-builds.libreoffice.org/daily/master/current.html I tested with: Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 6a064b1967e06e40be40817deff99d00c1a8554f CPU threads: 16; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win Locale: ko-KR (en_US); UI: en-US Calc: CL threaded and Version: 24.2.1.2 (X86_64) / LibreOffice Community Build ID: db4def46b0453cc22e2d0305797cf981b68ef5ac CPU threads: 16; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
(In reply to wjsim from comment #6) No crash for me when simply opening the file. Maybe related to font substitution or something like that? I did fiddle around a little and did find a crash: bug 160493
(In reply to wjsim from comment #6) > > (In reply to wjsim from comment #4) > > > I just wanted to mention the attached file results in a crash > > I tested with: > > Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community If you can still reproduce with a recent build and a clean profile, please open a new report, share the crash report that 24.2.2 generates, and collect a backtrace if you can. Thank you!