<input type="number"> value not shown in correct locale when decimal part is all zeroes
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
People
(Reporter: tesfabpel, Unassigned)
References
Details
Attachments
(4 files)
bug.png
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:130.0) Gecko/20100101 Firefox/130.0
Steps to reproduce:
A web page with lang="it" (or any language where the decimal separator is not the dot, like most European languages) containing an <input type="number"> with the value attribute set to any number with a decimal part consisting of all zeroes (like "100.00", instead of "100.01" or "100.50") will initially show the raw value, instead of being formatted in the user's locale.
Clicking on the up / down arrows of the type="number" will update the value correctly and show the new value correctly, so the problem is only when the page is first loaded.
According to the spec (https://html.spec.whatwg.org/multipage/input.html#number-state-(type=number)), the value of the value must be a "valid floating-point number" as defined here: https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#floating-point-numbers. So it should mean (if I read that correctly) that it must be formatted in a locale-less way (like the UNIX's C locale), so the HTML code should be correct.
Please see the attached "bug.htm" file (it only contains html without any external sources as you can see with a text editor).
Actual results:
The <input type="number"> is shown with a dot if its value contains all zeroes in the decimal part.
Expected results:
The <input type="number"> is shown in the page / user's locale under any circumstances.
Also tested on Firefox Nightly 132.0a1 (2024-09-19) (64 bit) (downloaded from: https://www.mozilla.org/it/firefox/all/desktop-nightly/linux64/it/).
|
||
Comment 4•7 months ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::DOM: Core & HTML' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Updated•7 months ago
|
|
|
||
Updated•7 months ago
|
I'm sorry, but I don't think this issue is related.
Bug 1622808 talks about leading zeroes not preserved, this bug talks about numbers being displayed in a different way than the user's locale.
To recap what I said, when rendering a correctly written web page (without errors of the W3's validator, ie. with the value attributes of input type="number" written according to the definition of "valid floating-point number" of the spec), I encountered two situations (so this defect is not even consistent):
<input type="number" name="price" step="0.01" value="100.50">is shown correctly in the user's locale right away;<input type="number" name="price2" step="0.01" value="100.00">: for this one the raw attribute text is used instead because it ends with ".00" (yes, strictly speaking, the decimal part isn't needed here but it's allowed by the spec). If the user clicks on the up/down arrows on the side of the input element, Firefox updates the value correctly and renders it correctly (showing eg.100,01).
If I attempt to write the numbers with a comma in the value attribute, I get from the validator because it's not what the spec mandates.
Bad value 100,50 for attribute value on element input: Expected a decimal point, e, E or a digit but saw , instead.
Bad value 100,00 for attribute value on element input: Expected a decimal point, e, E or a digit but saw , instead.
Please note also that I've written "user's locale" but in fact, I should have written "locale following the page's lang attribute" since the two may not be the same (like an italian user (it_IT) visiting a web page written in US english (en_US)).
In fact, trying with Chromium version 128.0.6613.119 (Official Build) Fedora Project (64 bit), I noticed a difference in behavior than Firefox (I may attach a screenshot, if requested).
Chromium renders the input elements in the user's locale (the way it is in the OS or how the browser is set in its settings page).
Firefox renders the input elements in the lang attribute the element is inside.
But this probably warrant a different bug report, I don't know...
|
|
||
Updated•7 months ago
|
|
||
Comment 7•7 months ago
|
||
It is unfortunately the same issue. The underlying issue is that when we localize 100.00, we get back 100 rather than 100,00, so we hit this code path: https://searchfox.org/mozilla-central/rev/1e8cec3727d6e09f4af41bb3d202b7a4c326ed84/dom/html/HTMLInputElement.cpp#4859
Mmh, ok I understand...
I think what Chromium does is a bit more complex than just leaving the input untouched.
Looking at how it behaves, it seems they parse the value as normal while taking into account the number of leading and trailing zeroes in the raw value. Then they localize the value and apply the trailing / leading zeroes back. I've not read the source code, though, so it may not be this exact algorithm.
Please see the new screenshot: leading_trailing_zeroes_ff_chromium.png.
Also, I've added this to bug.htm:
Price 3: <input type="number" name="price3" step="0.01" value="0000000.1"><br>
Sadly, mine is also not just a minor nitpick.
Besides being inconsistent, "ugly" and "confusing" for users, with this "input preserving" feature, a <input type="number" step="0.001" value="100.000"> will be rendered in Firefox as "100.000" even in the italian locale.
But, like many other languages in Europe, we use the dot . as the thousand separator!
An italian may read that as one-hundred-thousand instead of one-hundred with three zeroes (that would be written as "100,000").
In Italy, we use the comma as decimal separator and the dot as thousand separator. The opposite of english!
We are creating a website for a customer and they may complain about it (we are using Firefox as well as Chrome to develop and test)...
Reading the first comment of the bug 1622808, it references Bug 1586870 (which is 5 years old).
As you can see in the bug report, the user were not able to use the then Vodafone's web site because they were not able to enter their phone number (that starts with a 0).
In Mobile number field and Confirm Mobile Number when I enter 0 it gets removed automatically.
Actual results:
0 dissappears as soon as I enter different number.
Expected results:
zero must stay
Of course, this is an error in the Vodafone web page, since they are (sadly, STILL are, I've just tried the page) using type=number as a validation method (or maybe to make the mobile IME use the number pad) but, as any DBA will tell, treating a telephone number as an integer is wrong (like https://stackoverflow.com/a/24353813)...
Nowadays at least, the zeroes are preserved (it only changes when clicking on the up/down arrows) so that web page works.
It seems both Chromium and Firefox preserves the leading and trealing zeroes in the console, when using $0.value...
|
|
||
Comment 10•7 months ago
|
||
Yes, thus we need to fix our number localization to be more input preserving (and preserve leading and trailing zeros), which would fix these inconsistencies. That's bug 1622808 :)
Description
•