Open Bug 1199665 Opened 6 years ago Updated 11 days ago

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

Categories

(Core :: Layout: Form Controls, defect)

defect
Not set
normal

Tracking

()

ASSIGNED
Webcompat Priority P3
Tracking Status
firefox95 --- fix-optional

People

(Reporter: timbset, Assigned: jwatt, NeedInfo)

References

Details

(Keywords: parity-chrome, parity-edge, Whiteboard: [webcompat])

Attachments

(1 file)

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.
Component: Untriaged → Internationalization
Product: Firefox → Core
Version: 42 Branch → unspecified
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
(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,".
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.
(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.
Summary: It is impossible to use point in russian local instead of comma in input with the number type → 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
See Also: → 1216831
Status: UNCONFIRMED → NEW
Ever confirmed: true
See Also: → 1253606
Duplicate of this bug: 1253606
(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.
Whiteboard: [webcompat]
Assignee: nobody → jwatt
Status: NEW → ASSIGNED
Priority: -- → P2

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

Webcompat Priority: --- → ?

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

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

Flags: needinfo?(jwatt)
Duplicate of this bug: 1561236

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

Flags: needinfo?(jwatt)
Flags: needinfo?(jwatt)
Webcompat Priority: ? → P3

I think it belongs to Layout for triaging.

Component: Internationalization → Layout: Form Controls
Priority: P2 → --
Duplicate of this bug: 1691809
You need to log in before you can comment on or make changes to this bug.