I started to work on this, and I could not help investigating the
decimal separator problem I reported here :
https://issues.apache.org/jira/browse/OFBIZ-13297?focusedCommentId=18024867&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-18024867
Before displaying values in inputs, OFBiz formats values according to
the user locale. So depending on this locale, 1.2 might result as
value="1.2" (locale=en) or value="1,2" (locale="fr") on the final HTML
<input/>.
This is a problem because browsers do not behave consistently regarding
the decimal separator. For example :
* Firefox 143.03
o <input type="number" lang="en" value="1.2"/> -> 1.2
o <input type="number" lang="en" value="1,2"/> -> 1,2
o <input type="number" lang="fr" value="1.2"/> -> 1,2
o <input type="number" lang="fr" value="1,2"/> -> 1,2
* Chrome 141 (I suspect that Chrome always takes the browser locale)
o <input type="number" lang="en" value="1.2"/> -> 1,2
o <input type="number" lang="en" value="1,2"/> -> nothing
o <input type="number" lang="fr" value="1.2"/> -> 1,2
o <input type="number" lang="fr" value="1,2"/> -> nothing
(Note that we have a lang attribute on the HTML root element :
lang="fr-FR", which will be used by default)
I was able to fix the initial problem by
* always using the default locale language when parsing numeric values
(NumberConverters, L35, use Locale.getDefault(), so we always get
dots as decimal separators)
* always using the default locale language when building the input
value (ModelFormField, L369, use Locale.getDefault() when getting an
instance of NumberFormat)
So we always get a dot as decimal separator, and values are displayed
correctly in Chrome and Firefox.
Anyway, I'm not quite sure what would be the best choice here, but
ensure that we always end up with dots as decimal separator seems to be
a good option.
Le 07/10/2025 à 10:53, Florian Motteau a écrit :
OK, let's get started
Le 07/10/2025 à 09:17, Jacques Le Roux a écrit :
I think Deepak made a good synthesis
Le 07/10/2025 à 08:03, Florian Motteau a écrit :
Hi Jacques, Deepak,
Thank you for the quick feedback.
I also think we should implement the step attribute completely (not
only adding step="any" on number inputs), it is quite simple and I
believe it is useful (it allows the user to be guided, for example
showing him that we expect an integer right away).
If it's OK for you I can plan to work on that.
Le 07/10/2025 à 07:18, Deepak Dixit a écrit :
Hi Florian,
Thanks for the update.
Instead of reverting the entire change, I believe it would be
better to just
fix the number handling logic.
I agree with your proposal in principle, but rather than reading
the value
from the arithmetic properties, I suggest the following approach:
-
Set a default value as "any" for input type number
-
If a step is explicitly defined in the form attribute (for
input type
number) , the system should use that value.
This way, we retain flexibility while respecting the form
configuration.
Thanks & Regards
--
Deepak Dixit
ofbiz.apache.org
On Tue, Oct 7, 2025 at 10:11 AM Jacques Le Roux <
[email protected]> wrote:
Hi Florian, All,
I thought about it, and you are right.
One of the (old?) American saying I totally agree with is the
mantra "If
it ain't broke, don't fix it". We lack that in our "modern" troubling
consumerist world.
To be clear, in our case before the regression there was no limit on
decimals and it worked quite well.
So indeed no need to get further than "any" :)
Jacques
Le 06/10/2025 à 14:05, Florian Motteau a écrit :
Hi all,
Jacques spotted a regression following
https://issues.apache.org/jira/browse/OFBIZ-13183, in which I
introduced
a new "type" attribute on input
fields :
<text type="[text|number|email|password|tel..."/>
This attribute controls the "type" attribute on the resulting HTML
<input/> :
https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/input#type
The main goal was to implement the HTML standard way to specify
which
kind of data the user can enter, but also to be able to rely on
native
browser
validation. In other word, the goal was to get closer to the
standard
HTML way.
It appears that an <input type="number"/> cannot receive a decimal
value, unless we add a "step" attribute that define the granularity
(step="0.01",
step="0.1", step="1", and step="any" will allow all decimal values).
Inhttps://issues.apache.org/jira/browse/OFBIZ-13183 we also defined
that every numeric field would be entered with an <input
type="number"/>,
wihtout a default value for the "step" attribute. It results that
for
all entity-auto forms, numeric fields cannot receive decimal
values. Which
is
a problem :).
To tackle this, we could
* add step="any" on all <input type="number"/>, so when using
<text
type="number"/> there is no limitation about decimals on the
value
entered,
* support a new attribute "step" on <text type="number"/>, that
would
be rendered as step="..." on the HTML input, so we can choose on
each field what behaviour we want about decimals (this attribute
could have "any" as a default value) <-- I would go with this
* hold a default value in arithmetic.properties, but I feel
that this
property file is more about rules about numeric values in
different
functional contexts, and less about pure user interface concerns
Maybe we could think of something else, or revert the whole thing
altogether :), anyway I would be glad to fix this.
What do you think ?
Florian
*https://issues.apache.org/jira/browse/OFBIZ-13297
*https://issues.apache.org/jira/browse/OFBIZ-13183
*https://github.com/apache/ofbiz-framework/pull/862
*
https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/input#type
*
https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/input/number#step
