Bug 42145 - Don't accept erroneous values in conditional formatting
Summary: Don't accept erroneous values in conditional formatting
Status: RESOLVED NOTABUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: x86-64 (AMD64) Linux (All)
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Conditional-Formatting-Editing
  Show dependency treegraph
 
Reported: 2011-10-23 22:13 UTC by Kevin Hunter
Modified: 2021-05-14 00:44 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Malformed input that LO accepts, leaving human wondering what's going on. (20.52 KB, application/vnd.oasis.opendocument.spreadsheet)
2011-10-23 22:13 UTC, Kevin Hunter
Details
Associated screenshot (112.38 KB, image/png)
2011-10-24 06:58 UTC, Kevin Hunter
Details
Malformed input as viewed in LO 5.1.4.2 (106.24 KB, image/png)
2016-07-08 06:22 UTC, Kevin Hunter
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin Hunter 2011-10-23 22:13:11 UTC
Created attachment 52670 [details]
Malformed input that LO accepts, leaving human wondering what's going on.

This is more of a question than a bug report, but I'm not sure where to "discuss" or ask this question.

Distilled from a legitimate case of a program outputting slightly malformed input, the question is "how strict should LO be about interpreting it's input?"

The attached document and screenshot showcase an example where a bit of ODS input is slightly malformed.  This apparently doesn't bother LO, but certainly messes up the logic, as the background of the cells should be blue, not red (based on conditional formatting logic).

Content.xml is slightly malformed on lines 34 and 39.  Line 39 is the more "insidious" case as the output within LO even passes the basic inspection of a human eye.  (Click on cell C15, then click Format -> Conditional Formatting, and inspect the values.  It /looks/ right, doesn't it?)

This is "broken" as far back as OpenOffice 3.2, but I don't have any interim LibO versions installed; I'm not sure what version to set the dial to for this bug report.
Comment 1 Kevin Hunter 2011-10-23 22:15:53 UTC
Recreated as of:

$ git log -1
commit 237c5f0290169aa31e10990c05b7ea39d9fc70bd
Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com>
Date:   Sat Oct 22 12:36:07 2011 +0200

    another fix for 68dd19a368fb4afbf3eba4cb722f56b87f8ea7c1 on OSX

And never sure what is helpful to a developer tracking down a bug, so:

$ uname -a
Linux hani 2.6.35-30-generic #60-Ubuntu SMP Mon Sep 19 20:42:44 UTC 2011 x86_64 GNU/Linux

$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/bin/gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.6.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/usr/local --enable-ld=yes --enable-lto --enable-bootstrap
Thread model: posix
gcc version 4.6.1 (GCC)
Comment 2 Kevin Hunter 2011-10-24 06:58:23 UTC
Created attachment 52696 [details]
Associated screenshot

Doh!  Forgot to include the screenshot last night.  And the description in Comment 0 should read "cells should be blue, not green".
Comment 3 sasha.libreoffice 2012-04-17 00:33:13 UTC
Thanks for bugreport
reproducible in 3.3.4 and 3.5.2 on Fedora 64 bit
changing version to 3.3.4 as most early reproduced
When save this file and reload again, it works correctly

IMHO it is functionality request for adding warning for user if in opened odt file is some problem
Comment 4 Joel Madero 2016-07-04 05:58:20 UTC
Just updating version to inherited from because of the OP stating that it's been an issue since OOo 3.2.

@Kevin - from what I can tell this is still a "problem." If you could confirm on 5.1 or later that'd be great.

Thanks!
Comment 5 Kevin Hunter 2016-07-08 06:22:55 UTC
Created attachment 126122 [details]
Malformed input as viewed in LO 5.1.4.2

Yes, it appears to be still an issue.  What's more, either there's another malformed tidbit in the file, or LO now also does not show cell A4 (reference attached screenshot, where the content is shown in the input bar above, but not in the viewing area below).

For this test, I used the version packaged with Ubuntu Xenial.  From the About dialog:

    Version: 5.1.4.2
    Build ID: 1:5.1.4-0ubuntu1
    CPU Threads: 1; OS Version: Linux 4.4; UI Render: default;
    Locale: en-US (C)
Comment 6 Buovjaga 2021-03-18 15:10:12 UTC
(In reply to sasha.libreoffice from comment #3)
> IMHO it is functionality request for adding warning for user if in opened
> odt file is some problem

Design team: any idea about this? The report does not seem to be clearly defined as to what needs to be implemented.
Comment 7 Heiko Tietze 2021-03-19 08:59:38 UTC
What happens is that conditional formatting on C10 has three conditions with an invalid value on the second item (A10+B10) of the first condition. I guess the evaluation ignores this value and use just the first one, A10-B10, which is true so condition 1 is taken.

Another example of false input is entering a string into a field where numeric values are expected. The input is colored in those cases meaning we recognize it as an error.

What we should block the dialog until those errors are fixed.

PS: Please don't mess up with the content of odf files.
Comment 8 m.a.riosv 2021-05-14 00:44:48 UTC
BTW the bad expression in condition it's signaled with a red background color (7.1.3), so LibreOffice verify the formula has a correct syntax (not about their result).

I can't see a bug here