1199665 - Consider making <input type=number> always fall back to parsing numbers as English formatted numbers if parsing them as numbers formatted using the user's locale fails

Status: ASSIGNED

(Core :: Layout: Form Controls, defect)

Description

[Timofey]

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

Steps to reproduce:

1. Open this sample - http://jsfiddle.net/qwdtkpg5/
2. Try to tap some float number, e.g. 12.5
3. Stop on the third symbol (it should be "12." in input)


Actual results:

There is an empty string in span element. It is reproduced only in russian locale.


Expected results:

I want to see convertation of this value to "12," like it happens in Google Chrome because I want to update some value on every keypress so I want it to be correct value but not empty string.
If you try to use comma on step 3 (e.g. "12,"), everything is OK.

Comment 1

[Nickolay_Ponomarev]

There are two differences from the Chrome behavior here:
1) Firefox picks the decimal and the thousands separator based on the locale: https://developer.mozilla.org/en/docs/Web/HTML/Element/Input#Localization -- while Chrome (at least here) parses both ',' and '.' as a decimal separator.
2) Chrome keeps the trailing decimal separator ('.' for me or ',' in the Russian version as comment 0 seems to imply?) when returning the input's .value; Firefox returns an empty string when the text in the input doesn't seem to be a valid number

Comment 2

[Jonathan Watt [:jwatt]]

(In reply to Timofey from comment #0)
> I want to see convertation of this value to "12," like it happens in Google
> Chrome

This is confusing. Where are you seeing a conversion to "12," in Chrome when "12." is typed in? When "12." is typed in that should continue to be the string that is displayed to the user at that time. That string should also be the value of input.value. So I don't see how or where you would see conversion to "12,".

Comment 3

[Jonathan Watt [:jwatt]]

I assume what you mean is that you want to see input.value take the value _"12."_ instead of "", and the comma was just a mistake.

Comment 4

[Jonathan Watt [:jwatt]]

(In reply to Nickolay_Ponomarev from comment #1)
> There are two differences from the Chrome behavior here:
> 1) Firefox picks the decimal and the thousands separator based on the
> locale:
> https://developer.mozilla.org/en/docs/Web/HTML/Element/Input#Localization --
> while Chrome (at least here) parses both ',' and '.' as a decimal separator.

Actually I think what Chrome does is try to parse the number using the the locale, then if that fails it tries to parse it as a number in HTML's "valid floating point number" format.

What happens here in the Russian localized version of Firefox is that it sees "12." as "12" followed by a trailing grouping separator. A trailing decimal separator is fine, but a trailing grouping separator is invalid, which is why you end up with input.value being "".

Basically this boils down to you wanting localized versions of Firefox to fall back to parsing numbers as English formatted numbers if they don't parse as localized numbers. I.e. do what Chrome does.

There are problems with this approach though. For example consider typing in "12.345,6" in a Russian Firefox. As each character was typed in, input.value would change value as so:

  1  12  12  12.3  12.34  12345  12345.6

To avoid this from happening we would also need to stop accepting grouping separator characters, which also happens to be something that Chrome does.

Even if we did that there are still be issues though. For example, a user of a Russian Firefox may type in "12.345" with the intention that the "." is a thousand separator, not knowing that because we don't accept grouping separator characters we've fallen back to treating this as an English formatted number and the page will see it as the fractional number 12.345.

Comment 6

[Jonathan Watt [:jwatt]]

(In reply to Jonathan Watt [:jwatt] from comment #4)
> To avoid this from happening we would also need to stop accepting grouping
> separator characters, which also happens to be something that Chrome does.

I've put up a path for bug 1509057 to stop accepting grouping separator characters.

> Even if we did that there are still be issues though. For example, a user of
> a Russian Firefox may type in "12.345" with the intention that the "." is a
> thousand separator, not knowing that because we don't accept grouping
> separator characters we've fallen back to treating this as an English
> formatted number and the page will see it as the fractional number 12.345.

While this is true, based on other bugs that have been filed I guess it's likely to be far less of a problem than the fact that we don't currently fall back to parsing the user entered input as a number in HTML's "valid floating point number" format.

Comment 7

[Jonathan Watt [:jwatt]]

Attachment: Bug 1199665. Make <input type=number> always fall back to parsing numbers as English. r?mats

Comment 8

[Firefox Bug Husbandry Bot]

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

Comment 9

[Firefox Bug Husbandry Bot]

See bug 1547409. Migrating whiteboard priority tags to program flags.

Comment 10

[Mats Palmgren (inactive)]

@jwatt did you forget to land this by any chance? (See also review comment on the patch about filing a HTML spec issue.)

Comment 12

[Jonathan Watt [:jwatt]]

No, I realized that the patch as it is doesn't work properly. I need to cycle back and work on it.

Comment 13

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

I think it belongs to Layout for triaging.

Comment 15

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

The severity field for this bug is relatively low, S3. However, the bug has 3 duplicates.
:jwatt, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 16

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Comment 17

[Peter]

+1