Fixed: Decimal numbers not displayed correctly in input type=number (OFBIZ-13297) by florianMo · Pull Request #913 · apache/ofbiz-framework

florianMo · 2025-10-07T15:28:33Z

Fixed: Decimal numbers not displayed correctly in input type=number
(OFBIZ-13297)

`<input type="number"/>` does not accept decimals

Now that we use <input type="number"/> (https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/input/number, https://issues.apache.org/jira/browse/OFBIZ-13183) to display numeric values in forms, it is not possible to enter decimal values.

We need to support the step attribute (https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/input#step), and use any as default value, since any will allow any decimal value. This means adding a new step attribute on the <text/> form field, and render it as a step attribute on the HTML <input type="number"/>.
Supporting this attribute, developer will be able to define which kind of value he expects (integer, one decimal, two decimals...).

`<input type="number"/>` does not display decimal values correctly

<input type="number"/> are sensitive to the decimal separator used in their value attribute. Depending on the browser and the lang used, an input may or may not display its value in the HTML field. For example :

Firefox 143.03
- <input type="number" lang="en" value="1.2"/> -> displays 1.2
- <input type="number" lang="en" value="1,2"/> -> displays 1,2
- <input type="number" lang="fr" value="1.2"/> -> displays 1,2
- <input type="number" lang="fr" value="1,2"/> -> displays 1,2
Chrome 141
- <input type="number" lang="en" value="1.2"/> -> displays 1,2
- <input type="number" lang="en" value="1,2"/> -> displays nothing
- <input type="number" lang="fr" value="1.2"/> -> displays 1,2
- <input type="number" lang="fr" value="1,2"/> -> displays nothing

It vould seem reasonable to always use the same locale (en for example) to format numeric values before inserting it in a HTML input, and let the browser decide which decimal separator to use.

Thanks: Néréide team

JacquesLeRoux · 2025-10-07T17:41:30Z

Hi Florian,

I just tested, we have still the load and decimals value change issue at https://localhost:8443/catalog/control/EditProductPrices?productId=GZ-1000

Despite having

<html>
<body>
<!--StartFragment-->
<input type="number" name="price"
   value="18"     size="6"                 id="UpdateProductPrice_price_o_0"                     required   
   step="any"
<!--EndFragment-->
</body>
</html>

So it looks like a load issue. But if you try to enter 15,99 only 15 is saved. I know it's a WIP and a draft PR :) HTH

florianMo · 2025-10-08T07:14:36Z

Hi @JacquesLeRoux , it is related to my second point (as far as I know now, not sure yet what's happening here). When entering a decimal value in an input (dot or comma), we always get a decimal string with a dot in NumberConverters::fromString. If your locale is fr, then the parse operation will remove the decimals (I guess parse use only commas as decimal separator if locale is fr). If we use Locale.getDefault(), then decimals are parsed correctly.

After the value is saved, we have the same process for the display : OFBiz will grab the value from DB, and stringify it using the user locale. If the value is 1.2 in DB, it will become 1,2 (comma) in the display process (ModelFormField::getEntry L369). So we get an <input type="number" step="any" value="1,2"/> (comma), and the fact that the value contains a comma will lead to display issues depending on the browser. For example Chrome won't display this value, leading the user to believe that the value has not been saved (when in fact it has been).

I was able to "fix" this by using Locale.getDefault() (so en) on parsing (NumberConverters::fromString) and stringifying (ModelFormField::getEntry, when using NumberFormat on line 369), but it needs to be discussed, this is more of a quickfix to understand what's happening.

To summarize, I feel like using <input type="number"/> requires us to always use dots when building strings that are decimal values that will be used as an input value, so we never run into browser locale issues. And when receiving a string from a number input, we should always use the default locale as well, so dots are always considered as a decimal separator.

It should be noted that in HTML, locale can be defined on all elements, as a lang attribute. OFBiz sets the user locale on the <html/> element, but it can be overridden on a specific element. We could provide lang="en" on <input type="number" step="any" lang="en"/> to enforce a specific behavior. I did not test thoroughly, I'm not sure that it could be a viable solution in our case.

JacquesLeRoux · 2025-10-08T07:22:14Z

Thanks Florian, indeed we need to take decisions. Better do that openly on dev ML, the more brains the better.

JacquesLeRoux · 2025-10-08T08:37:17Z

Hi @florianMo, I noticed the new patch is shorter than the last one, normal?

OFBIZ-13297

This is a quick fix, not supposed to make its way to a release without further discussions! OFBIZ-13297

sonarqubecloud · 2025-10-08T08:39:33Z

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

JacquesLeRoux · 2025-10-08T08:49:27Z

Ah OK, seems still a WIP :)

florianMo · 2025-10-08T08:52:39Z

@JacquesLeRoux the implementation of the step attribute is ready for review, the last commit about always using en locale when parsing/stringifying is just a quickfix, its purpose is to demonstrate what goes wrong, providing a minimal/naive solution.

JacquesLeRoux · 2025-10-08T09:13:11Z

Thanks Florian, naïve but working 👍

JacquesLeRoux · 2025-10-08T09:49:39Z

@florianMo, I'm looking at the test issue

florianMo · 2025-10-08T09:52:16Z

thanks @JacquesLeRoux , I guess this test checks that the current timezone is used to parse numbers ? And my niave solution breaks that ?

JacquesLeRoux · 2025-10-08T10:00:42Z

Possible indeed @florianMo , I'll get back on this afternoon, not an hurry ;)

JacquesLeRoux · 2025-10-08T15:19:29Z

The issue is at ObjectTypeTests::simpleTypeOrObjectConvertTest L128

ofbiz-framework/framework/base/src/test/java/org/apache/ofbiz/base/util/ObjectTypeTests.java

Line 128 in 7dba6ac

assertNotEquals(label + ":bad-passed-timezone/locale", wanted,

The wanted argument is 12,345.67. At least on a French PC the value is 12 345,67. I did not test with another language.

So, in this specific case, the problems are the decimal and thousands separator https://en.wikipedia.org/wiki/Decimal_separator#Digit_grouping

I'm not sure, but since it's only a test, maybe it's easier to force separators value, say the English ones ("," and ".') and modify the calculated value to correspond to "wanted".

Adapting the "wanted" values upstream in function of local language, eg at

ofbiz-framework/framework/base/src/test/java/org/apache/ofbiz/base/util/ObjectTypeTests.java

Line 496 in 7dba6ac

    
           simpleTypeOrObjectConvertTestSingleMulti("BigDecimal->String", new BigDecimal("12345.67"),

ofbiz-framework/framework/base/src/test/java/org/apache/ofbiz/base/util/ObjectTypeTests.java

Line 497 in 7dba6ac

new String[] {"String", "java.lang.String"}, null, LOCALE_DATA, "12,345.67");

would be another solution.

I did not change nor tested anything yet.

JacquesLeRoux · 2025-10-08T15:30:43Z

Thinking about it, only the 2nd solution is serious. The 1st one is like testing 1=1 :)

JacquesLeRoux · 2025-10-19T16:56:48Z

Thank you for your work Florian, I'm closing after fixing the test issue.

florianMo · 2025-10-20T06:59:42Z

Thanks @JacquesLeRoux , is there a specific reason for not merging this PR, and creating a new commit instead ? By doing this we lose traceability (who did this, the original PR description where I describe the whole thing)

JacquesLeRoux · 2025-10-20T08:01:41Z

Hi Florian,

You are right, I should have pushed the PR just before fixing the test issue. That would have been better. Unfortunately It's now too late as, unlike with Subversion, it's complicated to change commits comments once pushed with Git.

But don't worry people interested by these information can still found it by following the Jira and information in it, notably the PR link. On the other hand alas indeed "git blame" does not help, I'm sorry.

The principal reason is that I forgot about the PR. Mostly because I crossed an OS issue while working on the test issue as I explained at bottom of the commit comment. I finally fixed it. But, in my defense, it took me all my attention that's why I mostly forgot the rest.

florianMo · 2025-10-20T08:19:58Z

OK @JacquesLeRoux I understand ! Not a big deal indeed.

florianMo marked this pull request as draft October 7, 2025 15:28

florianMo force-pushed the OFBIZ-13297 branch from 74ea277 to 785d1ab Compare October 8, 2025 08:09

florianMo added 2 commits October 8, 2025 10:37

Improved: support step attribute on number inputs

e87e846

OFBIZ-13297

Fixed: always use en locale when formatting/parsing numeric values

a47e482

This is a quick fix, not supposed to make its way to a release without further discussions! OFBIZ-13297

florianMo force-pushed the OFBIZ-13297 branch from ee9665a to a47e482 Compare October 8, 2025 08:38

JacquesLeRoux closed this Oct 19, 2025

Uh oh!

Conversation

florianMo commented Oct 7, 2025

<input type="number"/> does not accept decimals

<input type="number"/> does not display decimal values correctly

Uh oh!

JacquesLeRoux commented Oct 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

florianMo commented Oct 8, 2025

Uh oh!

JacquesLeRoux commented Oct 8, 2025

Uh oh!

JacquesLeRoux commented Oct 8, 2025

Uh oh!

sonarqubecloud Bot commented Oct 8, 2025

Quality Gate passed

Uh oh!

JacquesLeRoux commented Oct 8, 2025

Uh oh!

florianMo commented Oct 8, 2025

Uh oh!

JacquesLeRoux commented Oct 8, 2025

Uh oh!

JacquesLeRoux commented Oct 8, 2025

Uh oh!

florianMo commented Oct 8, 2025

Uh oh!

JacquesLeRoux commented Oct 8, 2025

Uh oh!

JacquesLeRoux commented Oct 8, 2025

Uh oh!

JacquesLeRoux commented Oct 8, 2025

Uh oh!

JacquesLeRoux commented Oct 19, 2025

Uh oh!

florianMo commented Oct 20, 2025

Uh oh!

JacquesLeRoux commented Oct 20, 2025

Uh oh!

florianMo commented Oct 20, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

`<input type="number"/>` does not accept decimals

`<input type="number"/>` does not display decimal values correctly

JacquesLeRoux commented Oct 7, 2025 •

edited

Loading