Description: In the attached when you go to a row and insert a row below, librewriter freezes and has to be terminated. It also often happens with some other tasks but presumably the same bug at heart. More than one computer was tried with it installed. Steps to Reproduce: 1.Go to a row 2.Insert row below 3. Actual Results: Librewriter freezes up Expected Results: Row insertion Reproducible: Always User Profile Reset: Yes Additional Info: 7.5.1.2 X86_64 on Win10 Build fcbaee479e84c6cd81291587d2ee68cba099e129
Created attachment 186293 [details] odt with table
Confirm with Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 7a7eb4aa21ca0c83db825fe8d5a5278611b391d8 CPU threads: 4; OS: Linux 5.19; UI render: default; VCL: gtk3 Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US Calc: threaded No repro with Version 4.1.0.0.alpha0+ (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a)
This seems to have begun at the below commit in bibisect repository/OS linux-64-6.5. Adding Cc: to László Németh ; Could you possibly take a look at this one? Thanks f9156a2d21314a5778601d7b7024712078235b8b is the first bad commit commit f9156a2d21314a5778601d7b7024712078235b8b Author: Jenkins Build User <tdf@pollux.tdf> Date: Thu Nov 21 19:52:55 2019 +0100 source 2c918aa51e5528b090e52fa31b10fa17cf2593ae 83236: tdf#125300 extend AddParaSpacingToTableCells with line spacing | https://gerrit.libreoffice.org/c/core/+/83236
crash with same stepts environment : Version: 7.5.0.3 (x86) / LibreOffice Community Build ID: c21113d003cd3efa8c53188764377a8272d9d6de CPU threads: 2; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: ro-RO (ro_RO); UI: en-GB Calc: threaded
It seems, this is an older regression. In LO 6.2 it was possible to insert arbitrary number of new rows, but inserting three new rows under the second row resulted freezing since LO 6.3. Testing: put the cursor in the cell "Windows size" in the second table row, and insert 3 new lines.
Note: bisected commit, where freezing in 6.2 was fixed (temporarily): commit ab9d3c535800e972d893ebc6415d0f616a89316b Author: Michael Stahl <Michael.Stahl@cib.de> Date: Mon Mar 11 15:43:31 2019 +0100 tdf#119253 sw: fix layout loop with row-span table This table has style:row-height="2.014cm" on its 2nd row (1142 twips). In the 1st call of FormatLayoutTab(), the 1st row of the table is split and the 2nd row moves to the next page. In the 2nd call of FormatLayoutTab(), the 1st row grows from 400 to 454 twips, presumably due to the style:min-row-height="0.801cm" on it. In the 3rd call of FormatLayoutTab(), the GetFollow()->ShouldBwdMoved() returns true and the 2nd row moves back again, because SwTabFrame::CalcHeightOfFirstContentLine() determines the height of the 2nd row as the maximum height of cells with rowspan=1 (400 twips), which fits on the 1st page, ignoring the style:row-height="2.014cm" on the row (1142 twips), which does not fit on the 1st page. This loops until "LoopControl_1 in SwLayAction::InternalAction" is triggered, and then eventually stops in 5.4 but loops even more since commit 18765b9fa739337d2d891513f6e2fb7c3ce23b50, for unknown reasons. Change-Id: I1a5c50d21c241e593419e63644ee758cdd9ed319 Reviewed-on: https://gerrit.libreoffice.org/69061 Tested-by: Jenkins Reviewed-by: Michael Stahl <Michael.Stahl@cib.de> (cherry picked from commit 00a86e8be983f7a92723dfe6cf5986974d77644e) Reviewed-on: https://gerrit.libreoffice.org/69085 Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(In reply to László Németh from comment #5) > It seems, this is an older regression. In LO 6.2 it was possible to insert > arbitrary number of new rows, but inserting three new rows under the second > row resulted freezing since LO 6.3. > > Testing: put the cursor in the cell "Windows size" in the second table row, > and insert 3 new lines. With these steps, the freeze on inserting rows happens for me in 6.2.0.3 too, and it started in libreoffice-5.3.0.1 (tested with linux-64-releases bibisect repo). So culprit should be listed in: https://wiki.documentfoundation.org/Releases/5.3.0/RC1 But I think we're hitting bug 121720, with that merged cell in Column A reaching the end of the page (a regression from 8a800eea613c0f5ad3302136766791dc58880fb3 for bug 104425) raal, which exact steps did you use for your test?
Still reproducible Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 748561425774fa40ab685fed80d113f7e8301158 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