Bug 142186 - Cell formatting code #,##0"." receives input field 123.45 as 12345
Summary: Cell formatting code #,##0"." receives input field 123.45 as 12345
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Eike Rathke
URL:
Whiteboard: target:7.2.0 target:7.1.4
Keywords:
Depends on:
Blocks: Number-Format
  Show dependency treegraph
 
Reported: 2021-05-10 04:19 UTC by joel roth
Modified: 2021-05-21 13:34 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description joel roth 2021-05-10 04:19:37 UTC
Description:
In a previous version of libreoffice, I used formatting code #,##0"." for displaying 123.45 as "123." In the current version (6.1.5-3+deb10u7), when this formatting is set for a cell, an input of 123.45, after ENTER, is displayed in the edit field as 12345. In other words, this format causes the decimal point in the input to be lost.



Steps to Reproduce:
0. Decimal separator is set to '.'
1. Format cell as #,##0"."
2. Enter 123.45


Actual Results:
12345 displayed in input/edit field, cell displayed as 12,345

Expected Results:
Input/edit field contains 123.45, cell content formatted as 123.


Reproducible: Always


User Profile Reset: Yes


OpenGL enabled: Yes

Additional Info:
Version: 6.1.5.2
Build ID: 1:6.1.5-3+deb10u7
CPU threads: 2; OS: Linux 4.19; UI render: default; VCL: x11; 
Locale: en-US (en_US.utf8); Calc: group threaded
Comment 1 Ming Hua 2021-05-10 04:44:51 UTC
Reproduced with 7.0.6:
Version: 7.0.6.2 (x64)
Build ID: 144abb84a525d8e30c9dbbefa69cbbf2d8d4ae3b
CPU threads: 2; OS: Windows 10.0 Build 19041; UI render: default; VCL: win
Locale: zh-CN (zh_CN); UI: en-US
Calc: threaded

@Joel: Do you remember which previous version that worked for you?  Or which old Debian version (Debian 9?) with the LibreOffice that worked?  This helps the QA people to decide when this bug possibly happened.
Comment 2 joel roth 2021-05-10 05:00:49 UTC
@Ming Thank you. The previous libreoffice version is 5.2.7-1+deb9u11. (I found this in /var/log/dpkg.log*)
Comment 3 Ming Hua 2021-05-10 06:54:26 UTC
(In reply to joel roth from comment #2)
> @Ming Thank you. The previous libreoffice version is 5.2.7-1+deb9u11.
Thanks for the quick feedback.

However when I tried with 5.2.7 on Windows 10, I can still reproduce the wrong behavior:
Version: 5.2.7.2 (x64)
Build ID: 2b7f1e640c46ceb28adf43ee075a6e8b8439ed10
CPU Threads: 2; OS Version: Windows 6.19; UI Render: default; 
Locale: zh-CN (zh_CN); Calc: group

This is the oldest version I have installed.

For completeness, also reproducible with 7.2/master daily build:
Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 18e5e948dd66e41f17b0a63bf631d98aee84a03b
CPU threads: 2; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win
Locale: zh-CN (zh_CN); UI: zh-CN
Calc: threaded

(In reply to joel roth from comment #0)
> Actual Results:
> 12345 displayed in input/edit field, cell displayed as 12,345
The actual result for me is slightly different (all three versions -- 5.2, 7.0, and master), I get:
12345 displayed in the formula bar, 12,345. displayed in cell.  Note the extra dot at the end for the cell display.

> Expected Results:
> Input/edit field contains 123.45, cell content formatted as 123.
Comment 4 Eike Rathke 2021-05-10 11:08:22 UTC
The confusion here is the literal string that equals the decimal separator. Those literal strings are skipped when scanning the input, like 00"x"00"y"00 will accept an input of 12x34y56 as the number 123456.

Seems we need to exempt the decimal separator character. But then again, only if one of those is present..

Taking.
Comment 5 Commit Notification 2021-05-10 16:53:30 UTC
Eike Rathke committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/3561978410579c5222889eb7dce68f917b550334

Resolves: tdf#142186 Accept 123.45 fractional input on weird formats like 0"."

It will be available in 7.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 6 Eike Rathke 2021-05-10 16:56:36 UTC
Pending review https://gerrit.libreoffice.org/c/core/+/115277 for 7-1
Comment 7 Ming Hua 2021-05-11 00:41:08 UTC
(In reply to Commit Notification from comment #5)
> Eike Rathke committed a patch related to this issue.
> It has been pushed to "master":
> 
> https://git.libreoffice.org/core/commit/
> 3561978410579c5222889eb7dce68f917b550334
> 
> Resolves: tdf#142186 Accept 123.45 fractional input on weird formats like
> 0"."
Thanks for the quick fix, Eike!

I have a question though -- you call format code like 0"." weird, but what is the normal way to specify format for "I want the decimal point always displayed, but zero decimal places"?  I would think it's a reasonable and common enough requirement, and I tried format code #,###. which does not work.  Reading online help at https://help.libreoffice.org/7.2/en-US/text/shared/01/05020301.html didn't give me any enlightenment either.

Or is it proper to use #,###"." here, just don't put "." after format code 0?
Comment 8 Eike Rathke 2021-05-11 10:41:34 UTC
Weird in the sense that displaying a literal character that happens to equal the decimal separator without any decimals following is rather unusual (or I've not seen it in the wild). And will not work as intended if it was assigned using the default (not a fixed) number format locale and the document is opened in a locale that uses a different decimal separator character, it would still display the literal "." of course.

Note that using #,###. after save/reload becomes #,###"." because it is saved as

    <number:number-style style:name="N111">
      <number:number number:decimal-places="0" number:min-decimal-places="0" number:min-integer-digits="0" number:grouping="true"/>
      <number:text>.</number:text>
    </number:number-style>

(note the <number:text>.</number:text>) as otherwise there is no distinction between number:decimal-places="0" number:min-decimal-places="0" with or without decimal separator.

Out of interest: what does Excel display for #,###. and how does that survive a save/reload cycle?
Comment 9 Commit Notification 2021-05-12 15:24:05 UTC
Eike Rathke committed a patch related to this issue.
It has been pushed to "libreoffice-7-1":

https://git.libreoffice.org/core/commit/88772bcf331152f24dde343ffe694c85fea8b6d3

Resolves: tdf#142186 Accept 123.45 fractional input on weird formats like 0"."

It will be available in 7.1.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.
Comment 10 BogdanB 2021-05-19 08:19:04 UTC
Solved. Verified in
Version: 7.2.0.0.alpha1+ / LibreOffice Community
Build ID: b238522ca121ca8f863fe4d3394ade088a65ad01
CPU threads: 4; OS: Linux 5.8; UI render: default; VCL: gtk3
Locale: en-US (ro_RO.UTF-8); UI: en-US
Calc: threaded
Comment 11 Commit Notification 2021-05-21 13:34:20 UTC
Xisco Fauli committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/e8b2849f2d336e903992ff7a3483364085594d12

tdf#142186: sc_ucalc: Add unittest

It will be available in 7.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.