Description:
SUMMARY(EDITING,UI): A plain, simple, default spreadsheet containing only numbers can be caused to turn sluggish, create delays, and print (briefly,repeatedly) "adapt row height" messages at bottom of screen (with green progress bar) everytime activity occurs.

REPLICATION (using LibreCalc v7.1.5.2 x86 on windows 10):
I have attached "bug-adaptRowHeight.ods" which is nothing more than a default blank ODS spreadsheet with a large block of numbers (1M file, 8000x40 cells).  No formatting or anything. (If you think something is weird about this spreadsheet then just copy "numbers only" or "unformatted text" to your own new/blank spreadsheet instead and follow test.)

This bug isn't noticable if you only have a small spreadsheet with a few cells and that is why this spreadsheet (or similar large one) is needed.  (!) Your spreadsheet to test has to be large enough to be 'big' for your processor/cpu.  This one is for my machine but it is consumer/mobile dual celeron and if you have a massive dev setup you might need to increase spreadsheet size in order to see the effect.

OBSERVATION: with this spreadsheet open, use the arrow keys to move the cursor from cell to cell; notice there is no lag, no delay, and no flickering "adapt row height" message or progress bar appearing at the bottom.  The cursor movement is normal and snappy.

TEST STEP: Now select the entire spreadsheet and then click the font name dropdown arrow (as though you wanted to change the entire sheet's font).  The list of available fonts will drop open and the current sheet font will be highlighted (Liberation Sans).  

Now...use the down arrow key to move the highlight selection to then next font.  So (on my machine) "Liberation Sans" is highlighted and the font under it is "Liberation Sans Narrow".  Thus, press down arrow to highlight it (but don't select).

When you highlight "Liberation Sans Narrow" (or whatever font you have below the default; doesn't matter) LibreCalc will preview that font on the spreadsheet (but not actually change it yet; you would have to press enter to do that).

Instead, press ESC to leave the font dropdown and *NOT* make any changes to the spreadsheet. The entire spreadsheet is still "Liberation Sans". (And UNDO will be blanked out.)

BUG: again move the cursor around with arrow keys and notice there is now a delay and sluggishness!  Each move from cell to cell has a pause and also you will see the bottom of screen flicker words "adapt row height" with a quick green progress bar.  You didn't even change the spreadsheet, but just the act of previewing a different font has now permanently made the spreadsheet operate with a lag.  It has somehow "damaged" the cells or sheet.

NOTES:
I have not found a way to reverse the program/cell 'damage' once the lag starts (after preview or font change).  Since you didn't actually change the cells or font or formatting you can't just hit CTRL-Z to Undo.  There is nothing to undo!  You have to close the spreadsheet and reopen it to return to having no lag or no 'adapt row height' situation.

If you have created the lagging/bug/"adapt..." situation (such as you went ahead and changed the page font), you can save that file, close LibreCalc, and then open the file.  The lag/bug will go away (in other words the issue is NOT inherent in the actual file data stream.)  If you then preview or change font the bug will come back.

I have not found that program font settings (options) matter to this bug (anti-aliasing, use skia, show preview of fonts, etc).

The default/starting font of your spreadsheet or the font you preview doesn't seem to matter.  It is the act of previewing (or changing) from the starting/default font (on cells with contents) that breaks something.  (I used numbers, but presume text or formula contents have same issue.)

What matters is starting with a new/default/blank spreadsheet where the cells are untouched by any font actions.  Cursor movement will be fine.  Then paste in numbers (without formatting; "paste numbers" or "unformatted text") and THEN preview or change font at which point the bug appears.  This bug seems to require cell contents and cells need to be 'touched' by the font preview (or change) in order to be 'damaged' and cause 'adapt row height' problem.

Instead, if you take a default/new/blank spreadsheet, select the spreadsheet, and preview or change the sheet font BEFORE it has contents, and THEN paste a block of numbers ('paste numbers' or 'unformatted text') there will be no problem, no bug.  The pasted numbers will (properly) be in the new font and the delay/sluggishness "adapt row height" bug/problem will NOT happen.  (But if you THEN preview a different font it will.)

Steps to Reproduce:
above

Actual Results:
above

Expected Results:
above


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 7.1.5.2 (x86) / LibreOffice Community
Build ID: 85f04e9f809797b8199d13c421bd8a2b025d52b5
CPU threads: 2; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: threaded