Bug 131471 - Rendering of background changes due to conditional formatting fails in merged cells across multiple rows in some cases in Calc.
Summary: Rendering of background changes due to conditional formatting fails in merged...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
6.4.2.2 release
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Tibor Nagy
URL:
Whiteboard: target:24.2.0 target:7.6.0.2
Keywords:
: 155533 (view as bug list)
Depends on:
Blocks: Conditional-Formatting Calc-Merge-Split
  Show dependency treegraph
 
Reported: 2020-03-22 03:45 UTC by Eric B. Pratt
Modified: 2023-07-25 08:30 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Example of the bug. (16.86 KB, application/vnd.oasis.opendocument.spreadsheet)
2020-03-22 03:47 UTC, Eric B. Pratt
Details
Example of the range workaround. (16.84 KB, application/vnd.oasis.opendocument.spreadsheet)
2020-03-29 07:11 UTC, Eric B. Pratt
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Eric B. Pratt 2020-03-22 03:45:20 UTC
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
Comment 1 Eric B. Pratt 2020-03-22 03:47:06 UTC
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.
Comment 2 Eric B. Pratt 2020-03-22 03:51:26 UTC
I have now tried this with OpenGL rendering and without it.  It doesn't matter whether OpenGL is being used or not.
Comment 3 m_a_riosv 2020-03-22 12:08:03 UTC
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.
Comment 4 Eric B. Pratt 2020-03-29 07:11:01 UTC
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.
Comment 5 Eric B. Pratt 2020-03-29 07:11:50 UTC
Created attachment 159108 [details]
Example of the range workaround.
Comment 6 QA Administrators 2022-09-01 03:48:15 UTC Comment hidden (obsolete)
Comment 7 Eric B. Pratt 2022-09-01 04:10:35 UTC
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
Comment 8 Tibor Nagy 2023-07-10 17:27:05 UTC
*** Bug 155533 has been marked as a duplicate of this bug. ***
Comment 9 Commit Notification 2023-07-24 13:04:59 UTC
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.
Comment 10 Commit Notification 2023-07-25 08:30:20 UTC
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.