Bug 117882 - Deleting a row or adding a column decreases the height of the lines in spreadsheet.
Summary: Deleting a row or adding a column decreases the height of the lines in spread...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
(earliest affected)
4.1 all versions
Hardware: All All
: low minor
Assignee: Not Assigned
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Cell-Add-Delete
  Show dependency treegraph
Reported: 2018-05-29 16:04 UTC by Salim Habchi
Modified: 2023-03-19 10:29 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

test (12.75 KB, application/vnd.oasis.opendocument.spreadsheet)
2018-05-29 16:04 UTC, Salim Habchi
Screen before removing a row (549.97 KB, image/png)
2018-05-30 13:56 UTC, Salim Habchi
Screen after removing a row (522.55 KB, image/png)
2018-05-30 13:56 UTC, Salim Habchi

Note You need to log in before you can comment on or make changes to this bug.
Description Salim Habchi 2018-05-29 16:04:06 UTC
Created attachment 142385 [details]

Problem description:

When you delete a row or add a column it decreases the height of the rows in the spreadsheet

Steps to reproduce:

1. Open the attached file.
2. Delete the second row.

1. Open the attached file.
2. add a column between column B and C.

Operating System: All
Version: Master
Comment 1 Salim Habchi 2018-05-30 09:08:02 UTC
Apparently, this occurs when you have merged cells in the first column.
Comment 2 Jacques Guilleron 2018-05-30 13:44:53 UTC Comment hidden (obsolete)
Comment 3 Salim Habchi 2018-05-30 13:55:46 UTC Comment hidden (obsolete)
Comment 4 Salim Habchi 2018-05-30 13:56:28 UTC
Created attachment 142407 [details]
Screen before removing a row
Comment 5 Salim Habchi 2018-05-30 13:56:51 UTC
Created attachment 142408 [details]
Screen after removing a row
Comment 6 Jacques Guilleron 2018-05-30 22:47:34 UTC
Thank you for this information completion.
However, I still see no width modification. They are the same before and after the row deletting: 8.77 cm.
Obviously, I see the red arrow apearing after the deletting. I thought to a side effect, but when I use undo(Ctrl+z) and redo(Ctrl+y), those red arrows desappear.
Is this the problem you see here and do you correct it this way?
Comment 7 Salim Habchi 2018-05-31 09:56:24 UTC
Look at the row number 14 after removing the second row.
The text completely disappear.
Comment 8 Salim Habchi 2018-05-31 09:58:54 UTC
i don't see a red arrow but (Ctrl+z) and redo(Ctrl+y) works.
Comment 9 Salim Habchi 2018-06-08 08:07:15 UTC
I investigate this bug in my opinion the problem comes from this file.

libreoffice\sc\source\ui\docshell\docfunc.cxx in line 2425.

Calc uses a different deletion when you have merged cells in your spreadsheet.
Comment 10 Xisco Faulí 2018-06-12 08:26:46 UTC
Regression introduced by:

author	Markus Mohrhard <markus.mohrhard@googlemail.com>	2013-01-22 23:50:47 +0100
committer	Markus Mohrhard <markus.mohrhard@googlemail.com>	2013-01-22 23:52:09 +0100
commit 62bf434229f9f86469dea3123bc6180bd9979c2c (patch)
tree 4b64aae8b8f2e99a146e4afc931639638d3f3639
parent c4b3af1e9f069d7d922974565ee66a30fd5744e4 (diff)
reset automatic row height flag after import, fdo#59193

Bisected with: bibisect-41max

Adding Cc: to Markus Mohrhard

Moving to ASSIGNED
Comment 11 Salim Habchi 2018-06-26 14:57:26 UTC

I fixed the bug on version 5.4 of LibreOffice but the code is different on version 6.

I am still looking for a solution for version 6.
Comment 12 Xisco Faulí 2018-09-25 08:07:27 UTC Comment hidden (obsolete)
Comment 13 QA Administrators 2019-09-26 03:03:26 UTC Comment hidden (obsolete)
Comment 14 david.vantyghem 2020-07-16 20:04:32 UTC Comment hidden (obsolete)
Comment 15 david.vantyghem 2020-07-16 20:07:01 UTC Comment hidden (obsolete)
Comment 16 Michael Weghorn 2020-07-17 05:45:48 UTC
(In reply to david.vantyghem from comment #14)
> Bug still existing in LibreOffice version Version

Thanks for rechecking.
The "Version" field is used for the earliest version affected though, so should stay unchanged.
Comment 17 Timur 2021-03-18 07:53:51 UTC
Repro 7.2+. But row 14 is already small on fileopen. That seems more clear than Lo 4.1 where that row becomes wrong only after delete of row 2.
I'm not convinced in regression, same problem with delete in 3.5.7, although it looks fine on fileopen. 
In OO 3.3 first row is smaller. 
Workaround is to Optimal height all or used rows. 
I decrease importance. It should be raised if repro steps from scratch can be found or similar bugs related via See Also.
Comment 18 QA Administrators 2023-03-19 03:25:36 UTC Comment hidden (obsolete)
Comment 19 ady 2023-03-19 09:50:02 UTC
The behavior as of:

Version: (x64) / LibreOffice Community
Build ID: 9c0871452b3918c1019dde9bfac75448afc4b57f
CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: default; VCL: win
Locale: en-US (es_AR); UI: en-US
Calc: CL

...is different than the original in comment 0 when comparing to the screenshot in comment 4, as Timur describes in comment 17, but there is still an issue.

1. Open attachment 142385 [details] from comment 0.
2. Click cell B1.
3. Menu Format > Rows > Height...
3.1. Note the value. [ESC]
4. Click cell B14.
5. Menu Format > Rows > Height...
5.1. Note the value. [ESC]
6. Right-click header row 14 > Row Height...
6.1. Note the value. [ESC]
7. Select cell B14:C14 (or _select_ at least one cell in row 14)
8. Right-click header row 14 > Row Height...
8.1. Note the value. [ESC]

Value in 6.1 equals value in 3.1 > incorrect.
Value in 6.1 differs value in 5.1 > incorrect.
Value in 8.1 equals value in 5.1 > OK.

This seems to be related to the merged cells in column A.

When no cell is selected, right-click row header > Row Height... provides information of the first row of the merged cells of column A.

I haven't tested whether this is always about column A, or it would happen also for freeze panes and/or split windows situations (i.e. when the "first" column is not necessarily column A).

Side-note: unmerging and [ctrl]+[z] leaves a different height than what was initially set.