When selecting columns and modifying the column width in Calc it is possible to insert an invalid input ( , . / <> ? ; ' : " [] {} \ | -_ = +. ). If all columns are selected, this may lead to unexpected column or row behavior which users perceive as sheet corruption Wrong inputs in LO are from OO, but "corruption" is not, it started from 6.1. LO would ignore many wrong inputs (like = or ++) but would behave weird with some, like /. commit 5a56b72413d5f555c854e36d3bd2fd50ec21644c [log] author Caolán McNamara <caolanm@redhat.com> Tue Aug 14 13:43:51 2018 +0100 committer Mike Kaganski <mike.kaganski@collabora.com> Tue Aug 14 22:26:00 2018 +0200 Resolves: tdf#119251 parse non-default units in user inputted values (in Writer) Caolan, please see. Mike opined: we likely need to make sure that all characters were processed when parsing the string (so whitespace was skipped, units recognized, and numbers processed); and when just anything was invalid, the operation should be rejected.
Created attachment 187198 [details] Columns Depending on input, there may be different ways how *all* columns (or rows) are corrupted. Here is an example.
Thanks Timur. Reproduced in: Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 002ae41bb6088002ba3ed0188ac822fb823a23f9 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Characters are stripped. Related: if using a comma instead of the locale's decimal point by mistake (or, I imagine, vice versa), it is silently stripped and results in a much larger width.
One issue, the way things are now at least, is that we do detect a bogus string in Formatter::ImplGetValue but use "m_dDefaultValue" and that itself defaults to 0 so junk of -=-=-=[] effectively turns into 0 and doesn't remain at the last valid number. There may be other issues, but lets address that first and see how it plays out.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/4ae776b842a8b6f065206d3250113493fd688756 tdf#155241 keep current MetricSpinButton value if unparseable junk input It will be available in 7.6.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.
caolan->timur: does that solve the problem from your perspective?
Thanks Caolan! This seems good, I tested with those that made problem> wrong decimal point and / Let's see how it will behave with users who can press what tech-savvy wouldn't think of.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-7-5": https://git.libreoffice.org/core/commit/0d0841dc8faccc7d7d3d8d463916dd73a7c061a1 tdf#155241 keep current MetricSpinButton value if unparseable junk input It will be available in 7.5.4. 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.
REOPENED because the patch was reverted for bug 157168.