Bug 153692 - Table layout split differently after undoing delete row
Summary: Table layout split differently after undoing delete row
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.0.0.3 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Writer-Tables Undo-Redo
  Show dependency tree / graph
 
Reported: 2023-02-17 14:03 UTC by Telesto
Modified: 2024-08-09 12:16 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2023-02-17 14:03:06 UTC 
Description:
Table layout split differently after undoing delete row

Steps to Reproduce:
1. Open attachment 185440 [details] (bug 153610)
2. Go to page 40
3. Enter the bottom table cell containing 45:45
4. Press delete row button
5. Press Undo -> Broken layout

Addition:
6. Press Save
7. reload -> Document fine

Actual Results:
A) View jumps to total different area
B) Scroll the document/ or go go to page 40 -> Notice the tables being split differently
 

Expected Results:
Same layout as before undo


Reproducible: Always


User Profile Reset: No

Additional Info:
Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 37e3455a13ab5741104bf41d05a80e60a4612682
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
Comment 1 Telesto 2023-02-17 14:09:02 UTC 
Same in
Versie: 4.4.7.2 
Build ID: f3153a8b245191196a4b6b9abd1d0da16eead600
Locale: nl_NL

also in
Versie 4.0.0.3 (Bouw-id: 7545bee9c2a0782548772a21bc84a9dcc583b89)

stable in
LibreOffice 3.5.0rc3 
Build ID: 7e68ba2-a744ebf-1f241b7-c506db1-7d53735
Comment 2 Ezinne 2023-02-24 04:55:20 UTC 
Reproducible in:

Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 4a0d671706306661c4a5072ce4769dc47bc65f71
CPU threads: 4; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded
Comment 3 Buovjaga 2024-08-09 12:16:09 UTC 
(In reply to Telesto from comment #1)
> also in
> Versie 4.0.0.3 (Bouw-id: 7545bee9c2a0782548772a21bc84a9dcc583b89)

No coherent result here. A state in older versions is that there is already an empty space at the bottom of the page with 45:45. However, if I jump to this page immediately after opening, I can see the empty space does not yet exist. It appears after layouting is complete. In Linux 43max I can see states with this empty space, but sometimes even in the same commit it might be layouted without the empty space and staying like that consistently. Yet it can crash upon undoing the row deletion. This crashing continues in 44max.

I noticed in linux-64-5.2 repo the oldest has an empty space on the page, jumps after undo, but otherwise retains the layout. The master did not have an empty space initially, jumped and then had the empty space after undo. Apparently this started with commit 905e38c7c6c02ec618b9231545c45debba3a8a44
Author: Michael Stahl <mstahl@redhat.com>
Date:   Thu Jun 9 15:52:16 2016 +0200

    tdf#96089 sw: fix scope of bBreakAfter in InsertCnt_()
    
    The problem is that bBreakAfter is passed by reference to SwLayHelper
    and stored as a reference member there, so it has to live at least as
    long as pPageMaker.  (Unfortunately C++ can't statically check that.)
    
    This then somehow caused the number of pages created after initial load
    to be 812 instead of the correct 396 determined from the layout-cache in
    the bugdoc, and that then caused Drawing objects to move backward during
    the following re-pagination, and then SwDrawContact::Changed_() calls
    SetFlyFrmAttr() and that sets the document to modified, which triggers the
    AutoSave that was reported in the bug.
    
    (regression from b4b7703e4335460cf48bfd6440f116359994c8ff)

The history is so messy that I will not add keywords.