Created attachment 195111 [details] description of the bug and conditions for reproduction Version: 24.2.4.2 (X86_64) / LibreOffice Community Build ID: 51a6219feb6075d9a4c46691dcfe0cd9c4fff3c2 CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: fr-FR (fr_FR); UI: fr-FR Calc: threaded In a new calc sheet, create a table of 4 rows and 5 columns with cells filled with a double line text (line1<CTRL+ENTER>line2) The bug is visible only in these minimal conditions (no bug visible if 3 rows, 4 cols, 1 line text) Select 2 cells vertically (no bug if horizontally) in the table (wherever), click inside the font name (no change is needed) and key ENTER, then the bug is activated. Select 1 cell in the table (wherever), click inside the font name (no change) and key ENTER, then the bug is disactivated. Each time we select a new cell (mouse click or key ARROWS), we can see in the status bar, that the bug activates a processus adjusting the height of the lines (all the sheet). The more the sheet is complex, the more we have to wait the end of the processus. For the fun, try this magic trick : If activated, disactivate the bug Delete one column, activate the bug (you see nothing, because of the minimal conditions), then CTRL+Z until the deleted column is restored, then the bug is visible ! Same with the other parameters of the minimal conditions. Thanks in advance for fixing this issue.
I can't reproduce. Version: 24.2.5.1 (X86_64) / LibreOffice Community Build ID: 2ccb78ad6bdfe3f3356a7a7f294ec388775c5816 CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded Please test in safe mode, Menu/Help/Restart in Safe Mode
(In reply to m_a_riosv from comment #1) > I can't reproduce.> > Please test in safe mode, Menu/Help/Restart in Safe Mode Tested calc in safe mode: reproduced. Uninstalled libre office, restarted, reinstalled: reproduced. Video mkv made with OBS, but impossible to attach here.
Created attachment 195132 [details] sample file I think this is a duplicate of the following bug. Preview or changing font on sheet causes 'adapt row height' messages and cursor movement delay lags (editing,ui,formatting) https://bugs.documentfoundation.org/show_bug.cgi?id=144151 Bug reported in the example of filling one million cells This report shows that it also occurs in sheets made by ordinary users. I made a material to report a bug, but it was already reported, so I cancelled it. I will attach the sheet that I made at that time with the addition of this report. It is a reproduction procedure as already mentioned by the reporter. When you select two or more cells and preview a font, a delay occurs. If you select a cell and preview the font, the delay is removed. Of course, the delay will be canceled by restarting. In this example, the delay is adjusted so that it occurs in all the sheets. If you delete one of the sheets, the delay stops. However, if you undo the deletion, the delay starts again. The minimum unit seems to be slightly different between the restart from the Start Center and the real restart, so the minimum unit is adjusted so that the bug occurs even immediately after the real restart. For example: Formula [=1] x 167 Text ["a"] x 1000 Formula [=1] x 143 , Text ["a"] x 142 Formula [=REPT("A",1)] x 125 Formula [=SIN(1)] x 143 Formula [=1+2+3+4+5+6+7+8+9+10] x 42 All of these must be placed in at least two columns. Because it shows the smallest unit that can be checked, it may be difficult to check on an expensive PC. Linux seems to handle this bug quickly even on older PCs, so it may be difficult to check without looking carefully. (Translated by TexTra)
(In reply to nobu from comment #3) > I think this is a duplicate of the following bug. > Preview or changing font on sheet causes 'adapt row height' messages and > cursor movement delay lags (editing,ui,formatting) > https://bugs.documentfoundation.org/show_bug.cgi?id=144151 Thank you nobu, this is exactly the same phenomenon. I describe my configuration: asus zenbook core i5 1.1-1.5Ghz 8GB With a simple sheet filled with less than 200 lines with multiple lines of text and multiple fonts, the delay is horrible. I can't understand this is not already fixed since 2021. There is only a flag to put off after the process "adapt" has been done.
Also can not reproduce with steps of OP and attachment 195111 [details], nor with steps of comment 3 and attachment 195132 [details]. Flash of the status bar, assume that is the optimal height recalculation. But no visual delay nor is the message readable. Version: 24.2.4.2 (X86_64) / LibreOffice Community Build ID: 51a6219feb6075d9a4c46691dcfe0cd9c4fff3c2 CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: default; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded (In reply to Manu from comment #2) > Video mkv made with OBS, but impossible to attach here. Just reuse the "Add an attachment" link found above, the video will be accepted if it is not larger than 10MB (I think that is the limit), resample a smaller section of display or reduce resolution of saved capture if needed. (In reply to nobu from comment #3) > Created attachment 195132 [details] > sample file > > I think this is a duplicate of the following bug. > Preview or changing font on sheet causes 'adapt row height' messages and > cursor movement delay lags (editing,ui,formatting) > https://bugs.documentfoundation.org/show_bug.cgi?id=144151 > Bug reported in the example of filling one million cells > I retested bug 144151 using steps of cmmnt 3 there, and find it to be *fixed*. Also, for bug 124098 at the 24.8.0 release there is now a prompt for doing the recalculation on file Load. Found in UI at Tools -> Options -> LO Calc -> Formula
Created attachment 195144 [details] video of the reproduction of the bug (activation, disactivation)
(In reply to V Stuart Foote from comment #5) Thank you a lot for your participation in this investigation!!! > (In reply to Manu from comment #2) > > Video mkv made with OBS, but impossible to attach here. > > Just reuse the "Add an attachment" link found above, the video will be > accepted if it is not larger than 10MB (I think that is the limit), resample > a smaller section of display or reduce resolution of saved capture if needed. The file is 770ko, so the "(File size limit: 30000 KB)" is ok. In fact the problem was the content type. It is asked this: "Otherwise, choose a method for determining the content type. auto-detect select from list: plain text (text/plain) enter manually: " As there was a preselected "plain text", I wanted to select video (missing in the list), then I wrote "video" manually and I received this warning message: "The content type video is invalid. Valid types must be of the form foo/bar where foo is one of application, audio, image, message, model, multipart, text, video and bar must not contain any special characters (such as "=", "?", ...)." So I thought video was previously accepted (like citation in the warning message), but obviously not anymore accepted for any reason. Today, thanks to your help, I just let the auto-detect activated, and it accepted the file. > Also can not reproduce with steps of OP and attachment 195111 [details], nor > with steps of comment 3 and attachment 195132 [details]. Flash of the status > bar, assume that is the optimal height recalculation. But no visual delay > nor is the message readable. > > You said "not reproduce", but also "flash of the status bar". If you see the flash, then you have reproduced the bug. That's why I explained how to disactivate. Because if the flash was normal, then you shouldn't be able to disactivate it. Imagine the sheet is long to recalculate, and each move between cells recalculate the sheet, this is the long delay that lead me to investigate the problem. I can accept ONE recalculation if needed. But is it really necessary each time I move to another cell without modifying anything? At least now, we have a trick to stop the bug. So, if really nothing can be done to solve the problem, maybe the trick for disactivation manually should be added in the help or somewhere in order to help other users when they are in front of the doom loop adapting the height of lines... maybe also when the delay is very long, a warning box should be displayed in order to help the user to disactivate the problem?
*** This bug has been marked as a duplicate of bug 144151 ***