Description: If you enable 'Wrap text automatically' in a cell and then you delete part of the text, so that the text can fit into the original dimensions of the cell, the height of the cell doesn't shrink to 'wrap the text'. To make this work, you need to disable this feature and enable it again. Steps to Reproduce: 1. I write text that exceeds the length of a cell. 2. I enable 'Wrap text automatically': as result, the height of the cell increases. 3. I delete part of the text, so that the text now fits into the original width of the cell. Actual Results: The height of the cell doesn't decrease to adapt to the new size of the text. Expected Results: As 'Wrap text automatically' is enabled, the height of the cell should go back to its default value. Reproducible: Always User Profile Reset: No Additional Info: Version: 25.8.0.4 (X86_64) Build ID: 48f00303701489684e67c38c28aff00cd5929e67 CPU threads: 16; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Vulkan; VCL: win Locale: es-ES (es_ES); UI: en-GB Calc: CL threaded
Created attachment 202487 [details] Clip
Reproducible Version: 7.6.7.2 (X86_64) / LibreOffice Community Build ID: dd47e4b30cb7dab30588d6c79c651f218165e3c5 CPU threads: 16; OS: Windows 10.0 Build 26100; UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded And still with Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 7f4868348c14b305fcd75744e1e3544d0d3a5d61 CPU threads: 16; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded Latest version that works on the ones I have installed. Version: 6.4.7.2 (x64) Build ID: 639b8ac485750d5696d7590a72ef1b496725cfb5 CPU threads: 16; OS: Windows 10.0 Build 26100; UI render: GL; VCL: win; Locale: es-ES (es_ES); UI-Language: en-US Calc: CL I haven't been able to find out if this is a duplicate, but it's strange that it hasn't been reported yet.
Similar bugs are: https://bugs.documentfoundation.org/show_bug.cgi?id=131944 and https://bugs.documentfoundation.org/show_bug.cgi?id=162668 And here we have also some info: This seems to have begun at the below commit in bibisect repository/OS linux-64-24.2. Adding Cc: to Paris Oplopoios ; Could you possibly take a look at this one? Thanks 0fd3d8fa5041781bea37aeda264bda71a66c6152 is the first bad commit commit 0fd3d8fa5041781bea37aeda264bda71a66c6152 Author: Jenkins Build User <tdf@pollux.tdf> Date: Mon Aug 28 10:38:53 2023 +0200 source 1760ee4d328cfb6ba22a5b3c84016625b12adb25 155970: sc: Fix wrapText not being applied correctly on export | https://gerrit.libreoffice.org/c/core/+/155970
Version: 7.2.0.0.alpha0+ commit dca0374fb1edbd9bdeeaadda3f1866ce66b3a778 author Tor Lillqvist <tml@collabora.com> Fri Jan 29 16:03:29 2021 +0200 Don't bother shrinking row height when changing just one row interactively I.e. when manually entering a new value. This used to happen at least for a sample document in .xlsx format for cells with automatic wrap turned on. After entering a value, the row height was annoyingly shrunk by a few pixels, which looked weird and pointless, and caused unnecessary invalidation thrash in the online collaborative editing context. Change-Id: I3c77f7fb4e575f02e1dd7cdc18f2919f5eb3426e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110243 adding CC: Tor Lillqvist This may be intentional behavior and not a regression.
(In reply to Saburo from comment #4) > This may be intentional behavior and not a regression. @Buovjaga Who to ask? Tor isn't around anymore, as far I'm aware
(In reply to Telesto from comment #5) > (In reply to Saburo from comment #4) > > This may be intentional behavior and not a regression. > > @Buovjaga > Who to ask? Tor isn't around anymore, as far I'm aware The name of the email gives a hint, "Don't use this account...", that email has not worked in a long time (the name has the actually working email). Tor is actually still around, doing some work again, but I don't think he is interested in this. I guess the change was intentional, but I'm not sure, if it's fair to ignore such potential height adjustments. Maybe the underlying issue on the Online side could be dealt with instead (or has been already).