Description: With merged cells spanning multiple rows, rendering of conditional formatting when that formatting is a background color and font color change fails in some cases. For instance, if a 3x3 grid of 2x2 merged cells has conditional formatting applied to all cells, the last row of 2x2 cells in the grid will only partially change background when the condition is met. All other merged cells in the grid display their formatting properly. It does not matter how many rows or columns are in the grid. The rendering bug manifests as only one of the rows the 2x2 merged cell changing its background. Sometimes the top row of the multi-row merged cell changes background colors and sometimes it's only the bottom row. I have not yet been able to determine if this is random or if certain things trigger it to change which row is affected. The bug appears to disappear when you save the file or when opening the file. It appears as soon as you trigger a change that causes the condition for the formatting to be evaluated again after opening the file or after saving the file but not closing it. This behavior happens in safe mode and with a fresh user profile. I have tried this under Windows 7 Ultimate and Slackware Linux running KDE. Steps to Reproduce: 1. Create a 3x3 grid of merged 2x2 cells. 2. Apply conditional formatting to change the background color and foreground color of the merged cells when a "Formula is" result is true based on an arbitrary calculation and cell value. 3. Watch the fail happen. Actual Results: This is in the Description field. Expected Results: The background color should change completely for every merged cell that meets the condition of the conditional formatting. Reproducible: Always User Profile Reset: Yes OpenGL enabled: Yes Additional Info: Version: 6.4.2.2 (x64) Build ID: 4e471d8c02c9c90f512f7f9ead8875b57fcb1ec3 CPU threads: 8; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: default; VCL: win; Locale: en-US (en_US); UI-Language: en-US Calc: threaded
Created attachment 158861 [details] Example of the bug. This is spreadsheet exhibits the problem. Instructions are included in the text of the sheet about how to cause the problem to manifest.
I have now tried this with OpenGL rendering and without it. It doesn't matter whether OpenGL is being used or not.
Reproducible. Version: 6.4.2.2 (x64) Build ID: 4e471d8c02c9c90f512f7f9ead8875b57fcb1ec3 CPU threads: 4; OS: Windows 10.0 Build 19587; UI render: GL; VCL: win; Locale: es-ES (es_ES); UI-Language: en-US Calc: CL Looks like a recalculation issue, doing a hard recalc [alt+ctr+f9] shows fine.
I have found a workaround that may help pinpoint the bug a little more closely. In the first attachment, the conditional formatting was applied by these steps: 1) Select one of the merged cells 2) Create and apply the conditional formatting to it 3) Copy and paste the cell to the other merged cells that use the same condition However, I have tried this a different way that appears to solve the problem from a user's perspective. By replacing step 1 above with selecting all the cells in a continuous range and skipping step 3, the problem does not manifest. 1) Select desired cells in a continuous range 2) Create and apply the conditional formatting to them I'm uploading a new attachment that shows the selected range method. However, in this attachment, I did not precisely follow the method described above. I used the previous attachment that showed the problem and opened the "Manage Conditional Formatting" dialogue. Then I replaced the comma separated list of cells to apply each format with a range that included all of the merged cells that needed that condition. So this is not something that requires the condition to be set with ranges at the creation of the conditional formatting instance. In the example, it also doesn't matter whether the range for the third merged cell column is R11:R27 or R11:S28. Both ranges work without showing the bug. While this workaround does suffice for my situation, if a non-continuous set of cells needs the same conditional formatting rule, the bug will still manifest unless someone finds a way to create the same conditional formatting rule multiple times. And example of such a change could be introducing something into each instance of the formula that doesn't change the result of the formula, like IF(1=1,"",""). Each time you need this, you could simply change 1=1 to 2=2 or 3=3 and so on. Of course, that is only meant as a short term workaround and a patch would be preferred.
Created attachment 159108 [details] Example of the range workaround.
Dear Eric B. Pratt, 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
The problem still shows up in the latest LibreOffice. Version: 7.3.2.2 (x64) / LibreOffice Community Build ID: 49f2b1bff42cfccbd8f788c8dc32c1c309559be0 CPU threads: 16; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL
*** Bug 155533 has been marked as a duplicate of this bug. ***
Tibor Nagy committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/f142b3e84f97ae678bd0a94614e867d369680458 tdf#131471 sc: fix background color of conditional formatting style It will be available in 24.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Tibor Nagy committed a patch related to this issue. It has been pushed to "libreoffice-7-6": https://git.libreoffice.org/core/commit/830f501147f830d5d1eeac601d97f9720d7b80f9 tdf#131471 sc: fix background color of conditional formatting style It will be available in 7.6.0.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.