Summary: | Conditional Formatting (still) Corrupted by Column Insert | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | mwelinder |
Component: | Calc | Assignee: | Not Assigned <libreoffice-bugs> |
Status: | NEW --- | ||
Severity: | minor | CC: | dennisfrancis.in, kelemeng, kohei, l.lunak, xiscofauli |
Priority: | lowest | Keywords: | bibisected, bisected |
Version: | Inherited From OOo | ||
Hardware: | All | ||
OS: | All | ||
See Also: | https://bugs.documentfoundation.org/show_bug.cgi?id=78402 | ||
Whiteboard: | |||
Crash report or crash signature: | Regression By: | ||
Bug Depends on: | |||
Bug Blocks: | 87351 | ||
Attachments: |
cf1.ods
cf2.ods |
Description
mwelinder
2020-07-13 02:12:49 UTC
Created attachment 162948 [details]
cf1.ods
Insert before column C works fine with this file.
Created attachment 162949 [details]
cf2.ods
Insert column before column C fails with this file.
Reproduced in Version: 7.1.0.0.alpha0+ Build ID: d851a02df57ab378ed0cc6d9362516de09c3279c CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Regression introduced by: https://cgit.freedesktop.org/libreoffice/core/commit/?id=a93bb27aa46c84410c8848a6118d5d63d47be92c author Kohei Yoshida <kohei.yoshida@collabora.com> 2014-05-13 12:35:24 -0400 committer Kohei Yoshida <kohei.yoshida@collabora.com> 2014-05-13 12:37:14 -0400 commit a93bb27aa46c84410c8848a6118d5d63d47be92c (patch) tree f73842e0d78806d9b62980358485b363eb5a3a10 parent 49bf3a1f5f38cdf259101b15a19d546b32151463 (diff) fdo#78402: Adjust references of validity entries as appropriate. Bisected with: bibisect-43max Adding Cc: to Kohei Yoshida @Dennis, @Luboš, I thought you might be interested in this issue repro 7.3+ repro 7.6+ Bah - I should have bibisected myself. This bibisect result is not accurate. Sure, the cells H7:I9 look fine before Kohei's commit, but the same problem described is seen on cells F14:G16 (except in reverse). That problem was already seen in OOo 3.3. This cannot be a bug AFAICS. There is only one formula that describes the formatting for all the cells. The formula basically breaks down to "look at the cell 4 columns ahead of you and see whether it is a 1 or a 2." After the column insertion, the top block needs to look 4 ahead, and the bottom block needs to look 5 ahead. One rule cannot say that. Now, granted, OP says that LO should be smart enough to replicate the rule so that each broken situation is fixed, and non-broken situations are unaffected. That seems a little far-fetched to me. Perhaps a calc genius could do that. But I certainly wouldn't expect a program to be able to be smart enough to know exactly what to do in this circumstance. And LO certainly didn't do it properly before this. Removing "regression" and lowering priority. |