Description: Every now and then, when you select and delete some columns in Calc, the columns left to the deleted ones lose all their formatting. Steps to Reproduce: 1. Select some entire columns by clicking a column header, hold the mouse button, and move to the right to select multiple columns. 2. Right-click one of the selected column headers and choose "Delete Columns". Actual Results: The selected colums are deleted, but some columns to the left of the deleted ones lose all formatting. Expected Results: The selected colums should be deleted without affecting any other cells. Reproducible: Sometimes User Profile Reset: Yes Additional Info: This happens every now and then, but I couldn't reliably reproduce it.
Please attach a sample file, reduce the size as much as possible without private information, and paste the information in Menu/Help/About LibreOffice, there is a copy icon.
Created attachment 195303 [details] Example document
Example document added as requested. LibreOffice version information: Version: 24.2.5.2 (X86_64) / LibreOffice Community Build ID: bffef4ea93e59bebbeaf7f431bb02b1a39ee8a59 CPU threads: 8; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-US Calc: threaded
Reproducible Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: ccc3996cfcbebe14e9d5f3511906cfc64ddf3452 CPU threads: 16; OS: Windows 11 X86_64 (10.0 build 22631); UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded First version that fails on the ones I have installed. Version: 7.6.7.2 (X86_64) / LibreOffice Community Build ID: dd47e4b30cb7dab30588d6c79c651f218165e3c5 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 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 22631; UI render: GL; VCL: win; Locale: es-ES (es_ES); UI-Language: en-US Calc: CL
STR: 1. New Calc. 2. Cell A1: 100% [TAB] 3. Cell B1: [CTRL]+[SPACE BAR] 4. [CTRL]+[-] (that's the minus sign key; to delete the column) 5. [PgDn], [PgUp] (to scroll the main area so the view of the cell is refreshed). Actual result: Cell A1 shows the value 1 with cell format as General/Standard (instead of the equivalent 100%). Expected result: Cell A1 unmodified, showing 100% (cell format 0.00%). Problem: step 4 (see above) deletes the cell format of column A; it shouldn't. Please note that there are several minor variations of this problem. For example, with attachment 195303 [details], deleting column D only (instead of columns C:D), will delete the format of column B, whereas column A remains with its original format. This worked correctly as expected up until LO 7.5. The first branch where the problem can be reproduced is LO 7.6. Regression.
(In reply to ady from comment #5) > This worked correctly as expected up until LO 7.5. > > The first branch where the problem can be reproduced is LO 7.6. Regression. For bisecting, this might have started at some (rather later) point within the 7.5 branch as a cherry-pick / back-port of some patch introduced in the 7.6 branch. This report sounds very similar to tdf#156689. Maybe a bisect might confirm it.
This seems to have begun at the below commit in bibisect repository/OS linux-64-7.6$. Adding Cc: to Czeber László ; Could you possibly take a look at this one? Thanks 48d095549a2c5b45882c8a7f30d30f2bf1ad30fa is the first bad commit commit 48d095549a2c5b45882c8a7f30d30f2bf1ad30fa Author: Jenkins Build User <tdf@pollux.tdf> Date: Mon Oct 30 14:20:44 2023 +0100 source c37e74949cf3cd11b701e4aea943aba4e8c1d4f8 152814: tdf#153437 sc: fix broken formatting without performance regression | https://gerrit.libreoffice.org/c/core/+/152814
So this bug 162040 and also bug 156689 are both caused by the patches introduced in order to solve tdf#153437, with several commits, cherry-picks and back-ports. Some of the problems were reported just a couple of months after the original commits were pushed. ATM, it's been a year since the original reports, and 11 months since the first bisect. This is not only annoying but also generates a lot of unexpected problems – see the comments in aforementioned reports. Clearly Czeber László is not going to take a look at this any time soon. This report should have a higher priority by now, and hopefully some developer could solve it.
This is a clearly a duplicate of bug 156689 *** This bug has been marked as a duplicate of bug 156689 ***