Created attachment 104125 [details]
Example video

Created attachment 104126 [details]
Example spreadsheet

Hi Adam, I can confirm that with your attached file it happen.

But it's not clear how you create the file & with which version of LO? I tried to reproduce from scratch but I can't.

Could you provide steps to reproduce from scratch?

Hi, I didn't create this file so I don't know how it was created. Since it's and .ods file the devs should be able to look deep into it and find out what's inside that causing this problem.
The original file was an .xlsx so I guess it was made using Excel, I converted it to .ods. The problem existed in the .xlsx version too.

(In reply to comment #4)
> The original file was an .xlsx so I guess it was made using Excel, I
> converted it to .ods. The problem existed in the .xlsx version too.
I think it's better if you also attach that original XLSX

Yes please attach the xlsx also. Marking as NEEDINFO - once you attach please set to UNCONFIRMED. 

Also - asking devs to dig into a single test case that you're not even sure how it was made is a hard "sell" - they are way overworked and don't have time to address a single test case. Always better to have reproducible steps that we can do from scratch so we can find out if it's a larger problem or a single problem with a single file.

Created attachment 105731 [details]
Original xlsx

Here is the original xlsx. I removed the "secret" information contained in the file with Microsoft Excel 2010. The bug is still reproducible with it.
I didn't make this file so I don't know how it was made. :(

That document is perfect - that being said I have some input:

1. The actual adjustment of the row height is expected. By default row height is set to "optimal row height" - so when you delete the values in column A the height adjusts accordingly. To confirm this:
a. Delete content in column b/c/d and you won't see a change. This is because Column A has the greatest height so the optimal row height is dependent on it. Once you remove the Column A value then the optimal height is based on a different column.
OR
b. Adjust the row height first of the column - this removes the "optimal height" default and then delete the content. The height will not adjust.


BUT:

the issue is that undo does not change the height back and this is a regression.

Bodhi 2.x
LibreOffice 4.3.1.2 release
Works fine in bibisect package


So the only issue here is that auto height is not readjusting upon undo not that it adjusts to begin with. Updating title to reflect this. 

Repro Steps:
Open xlsx attachment
Delete content of cell A5

Observed:
Height adjusts (expected)

Undo

Observed: No adjustment back to previous height.

Expected: Readjust


Minor - Can slow down work but won't prevent high quality work
Medium - regression so bumped it up

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 f2554751603ad8537257b3cf52d6171056c76eeb is the first bad commit
commit f2554751603ad8537257b3cf52d6171056c76eeb
Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com>
Date:   Fri Oct 18 05:12:11 2013 +0000

    source-hash-f42768fe0b60ecbbe9c68d775329bf28c0690131
    
    commit f42768fe0b60ecbbe9c68d775329bf28c0690131
    Author:     Caolán McNamara <caolanm@redhat.com>
    AuthorDate: Mon Sep 2 11:00:05 2013 +0100
    Commit:     Caolán McNamara <caolanm@redhat.com>
    CommitDate: Mon Sep 2 12:22:34 2013 +0100
    
        Resolves: fdo#68794 blank placeholders when there is no known language yet
    
        Change-Id: I7f43144bd61ddc575d8b7094567433fdfd5ee291

:100644 100644 201a17de07e17bd7debfdfe6ca43381e0cbfb343 12e94aaaed81846299f7c651da9b7cdfdaea5416 M	ccache.log
:100644 100644 6cc4c780f897b089bb359873db4fccd70b0c81e5 3ea3177036d3389e1c40e9c6c93c81c233297cd7 M	commitmsg
:100644 100644 2153cb6a9483927f005548244e5b98d99dca72c1 0078d4a35a067ec61accb624b78ced5467d42364 M	dev-install.log
:100644 100644 5544a3ca7ed6b28cc305c7b50b859e415b2e25d0 43dbebe038278acde4ca66aa7e8abcced5bdd20c M	make.log
:040000 040000 c053397df7eeda869c774fb1a0ef0d24e38b7e90 e21ced5098ed0fafcf81768c9d8e8f8e4e34888f M	opt


Usage: git bisect [help|start|bad|good|skip|next|reset|visualize|replay|log|run]
joel@joel-Studio-1737:~/Documents/Work/Non-Profit/Libre-Office/bibisect$ git bisect log
# bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e
# good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932
git bisect start 'latest' 'oldest'
# good: [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb
git bisect good e02439a3d6297a1f5334fa558ddec5ef4212c574
# bad: [4850941efe43ae800be5c76e1102ab80ac2c085d] source-hash-980a6e552502f02f12c15bfb1c9f8e6269499f4b
git bisect bad 4850941efe43ae800be5c76e1102ab80ac2c085d
# skip: [a043626b542eb8314218d7439534dce2fc325304] source-hash-9379a922c07df3cdb7d567cc88dfaaa39ead3681
git bisect skip a043626b542eb8314218d7439534dce2fc325304
# skip: [aba65c3e4c0df07e4909aeefb758cdb688242bf6] source-hash-827524abfb4b577d08276fde40929a9adfb7ff1a
git bisect skip aba65c3e4c0df07e4909aeefb758cdb688242bf6
# skip: [aba65c3e4c0df07e4909aeefb758cdb688242bf6] source-hash-827524abfb4b577d08276fde40929a9adfb7ff1a
git bisect skip aba65c3e4c0df07e4909aeefb758cdb688242bf6
# bad: [c81a8a0dcfc1ed095a80e4485c89dd0fcaf73f31] source-hash-c69ed33628ec0b7abf6296539cf280d6c4265930
git bisect bad c81a8a0dcfc1ed095a80e4485c89dd0fcaf73f31
# bad: [c81a8a0dcfc1ed095a80e4485c89dd0fcaf73f31] source-hash-c69ed33628ec0b7abf6296539cf280d6c4265930
git bisect bad c81a8a0dcfc1ed095a80e4485c89dd0fcaf73f31
# bad: [1d4980621741d3050a5fe61b247c157d769988f2] source-hash-89d01a7d8028ddb765e02c116d202a2435894217
git bisect bad 1d4980621741d3050a5fe61b247c157d769988f2
# good: [ba096f438393091574da98fe7b8e6b05182a8971] source-hash-8499e78ca03c792f4fa2650e02b519094ba0baa8
git bisect good ba096f438393091574da98fe7b8e6b05182a8971
# good: [e75547cbd2d9d480ba13e119a8df8098c9d3a0a3] source-hash-69f686774cfeb803fdd63ed1ef07ff70550930de
git bisect good e75547cbd2d9d480ba13e119a8df8098c9d3a0a3
# good: [bac2489ff3b644bd046102e379bff5a6c6c469d9] source-hash-621c1e491e56db5416da1c763aaff862e8ede67a
git bisect good bac2489ff3b644bd046102e379bff5a6c6c469d9
# good: [0b24b35122b1aec8721035679954b10f82a23540] source-hash-cdab3d619ca0389d4c14e3b50fb66bbadcf5c52f
git bisect good 0b24b35122b1aec8721035679954b10f82a23540
# good: [21be8eddb95a12408b74f43d3effb9dc9821e99e] source-hash-bcc51fb2ebdf77a1cc089857775fd742085b45b6
git bisect good 21be8eddb95a12408b74f43d3effb9dc9821e99e
# good: [e33eaf662f84503c8de782d6677d9eb1b0b0d96b] source-hash-6c3d74e8b779b1eb2d9779ed84f1518e078113c4
git bisect good e33eaf662f84503c8de782d6677d9eb1b0b0d96b
# bad: [f2554751603ad8537257b3cf52d6171056c76eeb] source-hash-f42768fe0b60ecbbe9c68d775329bf28c0690131
git bisect bad f2554751603ad8537257b3cf52d6171056c76eeb

Joel:

"a. Delete content in column b/c/d and you won't see a change."

This is not true. If I delete the content of B6, C7, D8, E9, F10, etc... the height changes.

I disagree that the height of the row should change when content is deleted or background color is changed no matter what the "optimal row height" is.

That's a preference thing and you'll end up in endless debates over what is better. I'm just saying by default "optimal height" is set and that changes depending on what is in the cells. Imagine if you typed something in size 30 font, you'd want the height to adjust (by default) and then if you changed it back to size 10, you'd want it to adjust. So optimal height is staying and the behavior is remaining BUT the undo should function right

Ah - so I think I understand your point a bit better - ignore my last one. That being said - let me think about how to best handle the bug in terms of the undo problem, and the problem you're describing :) Apologies for last comment!

The bibisect only reflects the regression with undo - but the other thing is a valid report also and both are related so for now leaving in one report. Upon request from a developer I'll split it up into two different bug reports

Great, thank you!

There are a number of other bugs related to row height in 4.2 and later.

The below appears to be the commit at which the behaviour changed.

commit 547f4fec93a023ff244e3bf509baf4b8001effa0
Author: Kohei Yoshida <kohei.yoshida@gmail.com>
Date:   Fri Aug 30 23:40:52 2013 -0400

    First step toward showing mis-spelled words without modifying cells.
    
    There are still tons of problems to fix.
    
    Change-Id: Icae6e3d2c9b8b2266724d8d068abbab8acae96da

Confirmed in version 5.0.2.2 (Ubuntu 15.10).

Adding Cc: to Kohei Yoshida

The bug is still present in:

Verzió: 5.4.1.2
Build az.: 1:5.4.1-0ubuntu1
CPU szálak: 8; OS: Linux 4.13; Felületmegjelenítés: alapértelmezett; VCL: gtk3; 
Területi beállítások: hu-HU (hu_HU.UTF-8); Calc: CL

The bug is still present when I'm deleting the contents of some cells like in the example video. However changing the background color of the cells no longer adjusts their height.


Verzió: 6.1.2.1
Build az.: 1:6.1.2-0ubuntu1
CPU szálak: 8; OS: Linux 4.18; Felületmegjelenítés: alapértelmezett; VCL: gtk3; 
Területi beállítások: hu-HU (hu_HU.UTF-8); Calc: CL

Verzió: 6.3.2.2
Build az.: 1:6.3.2-0ubuntu2
CPU szálak: 8; OS: Linux 5.3; Felületmegjelenítés: alapértelmezett; VCL: gtk3; 
Területi beállítások: hu-HU (hu_HU.UTF-8); Felület nyelve: hu-HU
Calc: threaded