Description: Cell formatting (color) of some cells change after Undo Steps to Reproduce: 1. Open attachment 131664 [details] 2. Select the area between B6 K30 3. Cut (or delete all cell content) 4. Undo -> Notice formatting change for B13 and B11 (no before/ colored after) Actual Results: Formatting changes for cell B11 and B13. No formatting before.. formatted after Expected Results: Shouldn't happen Reproducible: Always User Profile Reset: No Additional Info: Version: 7.0.0.0.alpha1+ (x64) Build ID: f9790da286f2d2fa47f1748f8cfa6172c6622ca3 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win; Locale: de-CH (nl_NL); UI: en-US Calc: CL also in 6.1 but not in 6.0.6
Increasing importance.. It's a sneaky bug; something you maybe not notice.
Reproduced in: Version: 7.0.0.0.alpha1+ (x64) Build ID: a7f2239e649ea1b9ef611d758841584ab51abed0 CPU szálak: 4; OS: Windows 10.0 Build 17134; Felületmegjelenítés: Skia/Raster; VCL: win; Locale: hu-HU (hu_HU); UI: hu-HU Calc: CL
Bibisected using bibisect-win32-6.1 to: URL: https://cgit.freedesktop.org/libreoffice/core/commit/?id=3f614f431475e1bf3bb3bbeac59b0681309628b7 author: Mike Kaganski <mike.kaganski@collabora.com> committer: Eike Rathke <erack@redhat.com> summary: tdf#95295: don't add duplicate conditional formats Adding Cc: Mike Kaganski
Reproduced in: Version: 6.4.6.2 Build ID: 1:6.4.6-0ubuntu0.20.04.1 CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3; Locale: en-IN (en_IN); UI-Language: en-US Calc: threaded and also in : Version: 7.1.0.0.beta1 Build ID: 828a45a14a0b954e0e539f5a9a10ca31c81d8f53 CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: en-IN (en_IN); UI: en-US Calc: threaded
Still reproducible in Version: 7.2.0.0.alpha0+ / LibreOffice Community Build ID: 066799b4a162aa0a4bc6aa28339f1f943a13971e CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
In no way could it be high/critical, even telling about "something you maybe not notice". There is no data loss; the conditional formatting regions are merged in correct way (even though of course it should not happen on undo, which is a bug, but not a critical bug). The coloring is even restored on save-and-reload. Please don't play randomly with priority.
*** Bug 141068 has been marked as a duplicate of this bug. ***
Dear Telesto, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Created attachment 200560 [details] Test file for conditional formatting manoeuvres I can confirm one issue with Undo, leading to "fragmentation" of conditional formatting (see attached test file).
Created attachment 200564 [details] 1) Screenshot of CF in the file, in the original state. Screenshot of the simple test CF in the previously-attached file: column A is formatted according to column F. -1: blue 0: green +1: red
Created attachment 200565 [details] 2) With 2x copy paste, one inside, one just outside CF range: OK In this modification of the previous file: two copy-paste operations are tested → all OK so far (see screenshot in next attachment).
Created attachment 200566 [details] 2b) With 2x copy paste - OK (screenshot) After copying line 11 and pasting into 8 & 13, behaviour is OK so far. - Pasting into line 8 correctly recognises the same CF and doesn't break the range. - Pasting into line 13 (just beyond CF range, 12) correctly extends the CF range. → The CF range is now A4-A13, as expected.
Created attachment 200567 [details] 3) First undo of paste beyond CF range - still OK After both successful copy-paste operations, the 1st undo (beyond the CF range) works well the CF range is correctly restricted to A4-A12 as before – see screenshot in next attachment.
Created attachment 200568 [details] 3b) Screenshot of 1st undo - still OK. The 2nd paste operation (beyond CF range, line 13) has been correctly undone by the 1st Undo command.
Created attachment 200569 [details] 4) After 2nd undo: CF range broken Things don't go so well after the 2nd undo (paste into line 8, i.e. inside the original CF range): now, the original single CF entry for range A4-A12 is split into two separate CF entries: the original one A4:A7, A9:A12 and the "undone" one A8. Obviously, the Undo command doesn't undo the paste operation properly, with the restored cell A8 not recognised as being part of the original CF range – see next screenshot. Both CF ranges are identical, though, and can be "mended" by copy-paste - see further comments.
Created attachment 200570 [details] 4b) CF broken after 2nd undo - screenshot. Conditional formatting after 2nd undo (of paste into line 8, inside CF range A4-A12) → CF split into two conditions.
Created attachment 200571 [details] 5) Mended CF upon copy-paste of column A After reading the comments / discussions on different bugs, e.g.: https://bugs.documentfoundation.org/show_bug.cgi?id=153506 Apparently, LO Calc recognises identical adjacent CF and tries to merge them to avoid excessive duplications. I gave it a try, and it appears to work in this case: simply copying and pasting column A now "mends" the CF - see also next screenshot.
Created attachment 200572 [details] 5b) Screenshot of split CF copy-paste of A - now OK Copying line A and pasting it into line A (should in principle do nothing) apparently activates the aforementioned "CF merge" feature, and reverts to a single CF range.
Created attachment 200573 [details] Conclusion / "range conservation" Version: 25.2.2.2 (X86_64) / LibreOffice Community Build ID: 7370d4be9e3cf6031a51beef54ff3bda878e3fac CPU threads: 8; OS: macOS 12.7.6; UI render: default; VCL: osx Locale: fr-CH (fr_CH.UTF-8); UI: fr-FR Calc: threaded This is the LO version for comments 10-19. As a parting shot: although Calc is in general excellent, conditional formatting is one of the least robust features, as it is easily corrupted / fragmented. As the CF guide says: https://wiki.documentfoundation.org/images/d/d1/LibreOffice_Calc._Conditional_formatting_guide_EN.pdf "Unfortunately, many users don’t use conditional formatting in their work." Sadly, one understands why, and I tend to underuse it myself because it is not very robust. In particular here: Undo should be "Undo", i.e. revert to the exact same state as before the command, which is here not the case. Especially common is the "CF range fragmentation issue", see e.g. https://bugs.documentfoundation.org/show_bug.cgi?id=153506#c27 (Here, $C$3:$D$1503 became $C$3:$D$55;$C$58:$D$94;$C$96:$D$1503 and then much worse.) As some sort of workaround, I always maintain near the CF ranges of my files a cell that calculates what the range should be (see A20 in this attachment), whose value I can paste into the CF range if it starts to become fragmented.