[Libreoffice-bugs] [Bug 144151] New: font preview or change on sheet causes 'adapt row height' cursor movement action lags (EDITING, UI, FORMATTING)

Sat Aug 28 21:32:07 UTC 2021

https://bugs.documentfoundation.org/show_bug.cgi?id=144151

            Bug ID: 144151
           Summary: font preview or change on sheet causes 'adapt row
                    height' cursor movement action lags
                    (EDITING,UI,FORMATTING)
           Product: LibreOffice
           Version: 7.1.5.2 release
          Hardware: x86 (IA32)
                OS: Windows (All)
            Status: UNCONFIRMED
          Severity: normal
          Priority: medium
         Component: Calc
          Assignee: libreoffice-bugs at lists.freedesktop.org
          Reporter: casapr at jumplink.org

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

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20210828/65cac8b9/attachment.htm>