Bug 62939 - Issues of reformatting the text of a "number" field
Summary: Issues of reformatting the text of a "number" field
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Forms (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
URL: http://stackoverflow.com/questions/53...
Keywords: InRadar
Depends on: 65064 76613 78208 78326 93236
Blocks:
  Show dependency treegraph
 
Reported: 2011-06-18 14:41 PDT by Patrick Gillespie
Modified: 2012-08-07 21:43 PDT (History)
8 users (show)

See Also:


Attachments
Patch (7.32 KB, patch)
2011-07-20 00:54 PDT, Shinya Kawanaka
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Patrick Gillespie 2011-06-18 14:41:32 PDT
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
Comment 1 Kent Tamura 2011-06-21 00:58:23 PDT
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?
Comment 2 Eric Cain 2011-06-21 22:59:51 PDT
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
Comment 3 Eric Cain 2011-06-21 23:16:58 PDT
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?
Comment 4 Shinya Kawanaka 2011-07-20 00:54:02 PDT
Created attachment 101434 [details]
Patch
Comment 5 Kent Tamura 2011-07-20 01:03:45 PDT
(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?
Comment 6 Kent Tamura 2011-07-20 01:05:14 PDT
(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.
Comment 7 Shinya Kawanaka 2011-07-23 06:51:34 PDT
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?
Comment 8 Kent Tamura 2011-07-25 00:27:06 PDT
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"
Comment 9 Jon Lee 2011-09-06 13:07:55 PDT
<rdar://problem/9730100>
Comment 10 Kent Tamura 2012-03-11 23:08:20 PDT
This bug was fixed for platforms using LocalizedNumberICU such as Chromium. We still have the problem with platforms using LocalizedNumberMac (OS X and iOS).
Comment 11 Kent Tamura 2012-08-07 21:43:35 PDT
(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.