https://bugs.documentfoundation.org/show_bug.cgi?id=43804
--- Comment #8 from casa <cas...@jumplink.org> --- I have a VERY simple test case which demonstrates what appears to be the issue in this ticket. It does not involve open/loading of a file and is easily replicate with ONLY a plain/default spreadsheet having a block of numbers and then attempting to change the font. (Actually changing the font isn't even necessary!) 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. 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 as noticable if you only have a small spreadsheet with a few cells and that is why this spreadsheet (or similar large one) is useful. 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. TEST STEP: Now select the entire spreadsheet and then click the font name drop down 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 to 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). Instead, press ESC to leave the font dropdown and *NOT* make any changes to the spreadsheet. The entire spreadsheet is still "Liberation Sans". 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. 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. 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. The cells appear to require contents and 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. 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.) I am filing this bug comment under both: 124098 and 43804 (which somebody reopened and appears to cover same issue). -- You are receiving this mail because: You are the assignee for the bug.