Bug 62939 – Issues of reformatting the text of a "number" field

• Component: Forms
• Status: RESOLVED FIXED

[Patrick Gillespie]

A comma is being inserted into the text of a "number" field. According to the HTML5 standard (http://www.whatwg.org/specs/web-apps/current-work/multipage/number-state.html#number-state):

"The algorithm to convert a number to a string, given a number input, is as follows: Return a valid floating point number that represents input."

A user named "arcain" at Stack Overflow claims to have pinpointed the problem in Webkit and has a solution (see the top answer):

http://stackoverflow.com/questions/5345095/chrome-auto-formats-input-number

I was unable to find a bug report on the issue or contact information for arcain, and since I've been having the same problem I figured I'd write a bug report and point to his solution/analysis.

I also want to add that I can see the benefit of the formatting in some cases (so maybe it should be configurable), but developers should be able to turn it off. Since there is no "year" field in HTML5, it seems logical to use number instead, but with the comma, developers are unable to do that and there is no way for them (at least from what I know) to use a year field that is just a spinbox with a number in it.

Side note, the bug is also reported in Chrome here: http://code.google.com/p/chromium/issues/detail?id=78520

[Kent Tamura]

The purpose of introducing LocalizedNumber was to support localized decimal separators.  Supporting group separators in parsing is also helpful for users, and it is harmless. Supporting group separators in formatting and auto-reformatting are harmfull in some cases.

So, a short term solution woud be:
 * Don't reformat the user-input value if it is a valid number, and
 * Don't use group separators in formatting in order to avoid formatting of the initial value.

I think a long term solution would be:
   Introducing a CSS property to control number formatting.
  e.g.  -webkit-number-format: [ "none" | "auto" | format-string]
    "none" accepts only HTML5 format.
     "auto" is the current locale-dependent behavior.
     format-string is like "#,##0.###"

Comments?

[Eric Cain]

This is arcain from SO; thanks for submitting this bug report. I had been in the process of trying to reproduce the issue on Windows and Ubuntu with the lastest Webkit sources, but neither platform exhibited the issue, plus it took forever to build out test environments. When I looked closer, the LocalizedNumber* sources didn't even seem to be included in the build -- they were, however included in chromium. So, I was a bit confused over whether the issue was really webkit, or if it was chromium.
(In reply to comment #0)
> A comma is being inserted into the text of a "number" field. According to the HTML5 standard (http://www.whatwg.org/specs/web-apps/current-work/multipage/number-state.html#number-state):
> 
> "The algorithm to convert a number to a string, given a number input, is as follows: Return a valid floating point number that represents input."
> 
> A user named "arcain" at Stack Overflow claims to have pinpointed the problem in Webkit and has a solution (see the top answer):
> 
> http://stackoverflow.com/questions/5345095/chrome-auto-formats-input-number
> 
> I was unable to find a bug report on the issue or contact information for arcain, and since I've been having the same problem I figured I'd write a bug report and point to his solution/analysis.
> 
> I also want to add that I can see the benefit of the formatting in some cases (so maybe it should be configurable), but developers should be able to turn it off. Since there is no "year" field in HTML5, it seems logical to use number instead, but with the comma, developers are unable to do that and there is no way for them (at least from what I know) to use a year field that is just a spinbox with a number in it.
> 
> Side note, the bug is also reported in Chrome here: http://code.google.com/p/chromium/issues/detail?id=78520

[Eric Cain]

I agree with the approach to mitigate the current formatting issue with a quick fix, and then come back with a more comprehensive, configurable solution.

I am creating a patch for part of the short-term solution: addressing the inclusion of grouping characters. I'll attach it here for review when I have finished.

(In reply to comment #1)
> The purpose of introducing LocalizedNumber was to support localized decimal separators.  Supporting group separators in parsing is also helpful for users, and it is harmless. Supporting group separators in formatting and auto-reformatting are harmfull in some cases.
> 
> So, a short term solution woud be:
>  * Don't reformat the user-input value if it is a valid number, and
>  * Don't use group separators in formatting in order to avoid formatting of the initial value.
> 
> I think a long term solution would be:
>    Introducing a CSS property to control number formatting.
>   e.g.  -webkit-number-format: [ "none" | "auto" | format-string]
>     "none" accepts only HTML5 format.
>      "auto" is the current locale-dependent behavior.
>      format-string is like "#,##0.###"
> 
> Comments?

[Shinya Kawanaka]

Created attachment 101434 [details]
Patch

[Kent Tamura]

(In reply to comment #4)
> Created an attachment (id=101434) [details]
> Patch

The patch resolves only the second bullet in Comment #1, right?
Will you adress the first bullet?

[Kent Tamura]

(In reply to comment #4)
> Created an attachment (id=101434) [details]
> Patch

I think the patch will break fast/speech/input-appearance-numberandspeech.html.
You should add it to platform/chromium/test_expectations.txt.

[Shinya Kawanaka]

kent,

Sorry for late response.

Yes, that patch addresses only the second bullet in Comment #1.
The first bullet will take more time if I fix it.

So I've added a new bug
https://bugs.webkit.org/show_bug.cgi?id=65064
which only addresses the second bullet in Comment #1.

(In reply to comment #5)
> (In reply to comment #4)
> > Created an attachment (id=101434) [details] [details]
> > Patch
> 
> The patch resolves only the second bullet in Comment #1, right?
> Will you adress the first bullet?

[Kent Tamura]

Group separators aren't inserted by the patch in Bug 65064.

We still have reformatting issues.  For example, If a user specifies a value "012345678901234567890123456789" and changes the focus, the field value is reformatted to "12345678901234600000000000000"

[Jon Lee]

<rdar://problem/9730100>

[Kent Tamura]

This bug was fixed for platforms using LocalizedNumberICU such as Chromium. We still have the problem with platforms using LocalizedNumberMac (OS X and iOS).

[Kent Tamura]

(In reply to comment #10)
> This bug was fixed for platforms using LocalizedNumberICU such as Chromium. We still have the problem with platforms using LocalizedNumberMac (OS X and iOS).

This was fixed in Bug 93236.
Closing the bug.