1704077 - input field type="number" value=0.0 localization error with decimal seperator

Status: NEW

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

Description

[Christian Menzel]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.114 Safari/537.36

Steps to reproduce:

<input type="number" value="0.0">
vs.
<input type="number" value="0.1">

Browser localization needs to be GER (Germany)
or i suppose another Country using "," Comma to separate decimals.

You can not reproduce this by typing in an input field, it has to be in the input tag,
cause firefox shortens automaticly

Actual results:

0.0 -> is shown as 0.0
0.00 -> is shown as 0.00

0.1 -> is shown as 0,1 (correct)
0.10 -> is shown as 0,10 (correct)

REGEX: /.0+$/

Any Number followed by "." and zero(s)

Expected results:

0.0 -> 0,0
0.00 -> 0,00

Comment 1

[Christian Menzel]

I just tested this on Firefox on Mac but i don't think it's OS specific

Comment 2

[Mirko Brodesser (:mbrodesser) -- not reading bugmails currently]

On Ubuntu 20.04 in all cases, no comma is shown. Language is set to "de-DE" in the browser. System language is English.

Comment 3

[Mirko Brodesser (:mbrodesser) -- not reading bugmails currently]

Couldn't reproduce the issue on macOS either. System language there was English, language set in the browser to "de-de". Tested with release and Nightly.

:flod: I stumbled over https://blog.mozilla.org/l10n/2019/04/02/changing-the-language-of-firefox-directly-from-the-browser/ and inferred, setting the language in the browser should suffice to see the comma instead of the dot. Apparently it doesn't. Can you please shed some light on this?

Comment 4

[Francesco Lodolo [:flod]]

Changing the language of the browser doesn't necessarily change other intl settings, which might be still coming from the OS
https://firefox-source-docs.mozilla.org/intl/locale.html#regional-preferences

That's i18n territory, feel free to ask in #i18n on chat.mozilla.org (there's a new team who has ownership of that part).

For this specific bug, I would suggest to get a full picture of the Intl settings from about:support. In the RAW data, there will an Intl section, which in my case looks like this

  "intl": {
    "localeService": {
      "requested": [
        "it"
      ],
      "available": [
        "it",
        "en-US"
      ],
      "supported": [
        "it",
        "en-US"
      ],
      "regionalPrefs": [
        "it-IT",
        "en-IT"
      ],
      "defaultLocale": "it"
    },
    "osPrefs": {
      "systemLocales": [
        "it-IT",
        "en-IT"
      ],
      "regionalPrefsLocales": [
        "it-IT",
        "en-IT"
      ]
    }
  },

Comment 5

[Christian Menzel]

so... try this to reproduce:

<input type="number" value=0.0 lang='de'>
<input type="number" value=0.1 lang='de'>

i tested it today on Manjaro Linux

Comment 6

[Christian Menzel]

<input type="number" value="0.0" lang="de">
<input type="number" value="0.1" lang="de">

Comment 7

[Tom S. (please needinfo tschuster)]

I can reproduce this problem with the testcase in comment 6. I see 0.0 and 0,1. I am going to look if I can quickly figure out what is going on.

Comment 8

[Tom S. (please needinfo tschuster)]

The problem seems to be this code: https://searchfox.org/mozilla-central/rev/d8194cbbeaec11962ed67f83aea9984bf38f7c63/dom/html/HTMLInputElement.cpp#4556, which references bug 1622808.

The basic problem is that we convert 0.0 internally to 0, which parses in both German and English. 0,1 however only parses in German.

Comment 9

[Emilio Cobos Álvarez (:emilio)]

(In reply to Christian Menzel from comment #0)

Actual results:
[...]
0.1 -> is shown as 0,1 (correct)
0.10 -> is shown as 0,10 (correct)

This doesn't match my testing? data:text/html,<input type="number" value="0.10" lang=de> shows 0,1, not 0,10, what am I missing?

(In reply to Tom Schuster [:evilpie] from comment #8)

The problem seems to be this code: https://searchfox.org/mozilla-central/rev/d8194cbbeaec11962ed67f83aea9984bf38f7c63/dom/html/HTMLInputElement.cpp#4556, which references bug 1622808.

Yeah, bug 1622808 is a bit related. The issue is that our localization works on the number value, not the string value.

I suspect I wrote that code just to preserve existing behavior. If we remove that code, then we'd just show 0, not 0,0 (but we won't show 0.0 at least!). It might be an ok trade-off to make. Again, I'm not 100% sure if I wrote that code to preserve existing behavior or for other reason.

Maybe push to try with that condition removed and see what breaks? The most important one is the one above, for the .value getter, as that one is web exposed.

Comment 10

[Tom S. (please needinfo tschuster)]

I also see 0,1 and not 0,10.

Try push: https://treeherder.mozilla.org/jobs?repo=try&revision=c71e73351cea0b75bb4041a86ebc846004f11bf7

Comment 11

[Tom S. (please needinfo tschuster)]

I also noticed that Chrome doesn't seem to localize at all, at least with the data: snippet linked here?

Comment 12

[Emilio Cobos Álvarez (:emilio)]

(In reply to Tom Schuster [:evilpie] from comment #11)

I also noticed that Chrome doesn't seem to localize at all, at least with the data: snippet linked here?

Yeah chrome doesn't localize based on the <input> language, it always uses the Chrome UI language, AIUI.

Comment 14

[rafal1.1990]

I am using Firefox 104.0.1 (on a Linux set to German) and this problem still exists!
Why is it taking so long to fix this bug? I think the bug is critical enough that it should have been fixed long ago!

This example should demonstrate why I consider it so critical:

<input type="number" value="0.901">
<input type="number" value="1.000">

In the first case it is displayed as 0,901 and in the second case as 1.000

This is fatal because the . is considered a thousand separator in German. A user who sees these values will therefore probably assume that the second value means 1000!

If it is so difficult to solve the problem and simply display a , in both cases, I would find it better as a short-term solution to display only 1 instead of 1.000, but in the long term I think the browser locale should be respected. But it can't be that one value is displayed with
, and the other value with . because that is very confusing!

Comment 15

[jose.brihuega]

I have exactly the same issue with lang="es-ES" on Firefox 108.0 (both Windows and Ubuntu). The same form works fine on Edge and Chrome.

It's incredible that this bug is taking years and years to be fixed.

Comment 16

[Bernat]

Has there been some progress? This bug is very serious for some locales. Default values in inputs of type number are changed because of the wrong locale decimal separator. "1,000" (one) gets converted to "1.000" (one thousand). It works correctly on Chrome.

Comment 17

[jose.brihuega]

It's ridiculous that something like this takes years to fix.
It makes me think that Mozilla has a very America-centric vision.

Comment 18

[Bernat]

Here's a fix using Javascript for locales using comma as decimal separator:

    document.querySelectorAll("input[type=number]").forEach(function (element) {
        if (/^\d+\.0+$/.test(element.value)) {
            element.value = element.value.replace('.', ',');
        }
    });