1733151 - input type number doesn't localize the number if trailing decimal zero is present

Status: UNCONFIRMED

(Core :: DOM: Forms, defect, P3)

Description

[Thomas]

Attachment: Example output on German OS

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/94.0.4606.61 Safari/537.36

Steps to reproduce:

If using input fields with type number, the localization is not applied when the value ends with a zero decimal.

Example:
<input type="number" step="0.01" value="0.01" />
<br/>
<input type="number" step="0.01" value="0.00" />

The second number is not localized on a German windows.

Actual results:

The first number is localized correctly to: 0,01
The second number is not localized and shows: 0.00
(the . is not replaced with , )

Expected results:

The number should be formatted according to the locale, even if it ends with a decimal zero.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Layout: Form Controls' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Thomas]

I just stumbled upon a similar issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1704077
My environment is Win10 21H1, German windows and German FF installation.

Comment 3

[Hiroyuki Ikezoe (:hiro)]

Presumably this bug is in DOM input forms (or our I18N stuff).

Comment 4

[Anne (:annevk)]

Thanks Thomas!

Edgar, can you take a look at this?

Comment 5

[Edgar Chen [:edgar] (Parental leave until Oct. 09.)]

Bug 1622808 is also a bit related.

Currently HTMLInputElement use unum_parseDouble then unum_formatDouble to localize the number.
Since the localization would lose the leading/trailing zeros, e.g. 001 -> 1, so HTMLInputElement does something checking to try to preserve them. And 0.0 is a kind of corner case for that.

It would be good if there is some localization way that could be more input-preserving, e.g. 0001.1000 -> 0001,1000 for german.
Hi Zibi, is there any way that could a number be localized but keeps the leading/trailing zeros? (not sure if you are the right one to ask this, if not, could you help to redirect to the proper one?) Thanks!

Comment 6

[Zibi Braniecki [:zbraniecki][:gandalf]]

Dan and Greg are working on unification of our I18n and API refactor in preparation for ICU4X. I'm not sure about ICU4C, but in ICU4X we plan to support FixedDecimal which aims to store arbitrary precision for localization formatting scenarios - https://unicode-org.github.io/icu4x-docs/doc/icu_decimal/index.html

This would allow us to store 0.0 as FixedDecimal { value: 0, precision: 1 } ensuring that 0 is preserved, and then format it to 0,0 according to CLDR rules.

Dan and Greg should be in a better position to advise on how to use the current Unified I18n API for that (and move away from directly calling ICU4C :))

Comment 7

[Tom S [:evilpie]]

I think this is a duplicate of bug 1704077.

Comment 8

[Dan Minor [:dminor]]

The current code for handling the input in ICUUtils [1], ParseNumber and LocalizeNumber, use ICU4C calls that operate on doubles. There is an unum_formatDecimal that will operate on strings, instead of doubles, but as far as I can tell, there is no replacement for unum_parseDouble in ParseNumber.

Looking at the code in HTMLInputElement [2], it looks like we end up truncating the input as part of the parsing, since it eventually goes through unum_parseDouble. Without a better solution for parsing localized numbers as input, I don't think there is much we can do here. I'm not sure if parsing localized numbers is on the roadmap for ICU4X.

I filed Bug 1734932 to unify these calls under intl/components since I couldn't find a bug for this already on file.

[1] https://searchfox.org/mozilla-central/source/intl/unicharutil/util/ICUUtils.h
[2] https://searchfox.org/mozilla-central/rev/d8194cbbeaec11962ed67f83aea9984bf38f7c63/dom/html/HTMLInputElement.cpp#4530