[Webkit-unassigned] [Bug 48308] Too precise serialization from floating point number to string for "number" input elements

Mon Nov 1 01:16:43 PDT 2010

https://bugs.webkit.org/show_bug.cgi?id=48308

--- Comment #23 from Gavin Barraclough <barraclough at apple.com>  2010-11-01 01:16:43 PST ---
Hi Dai,

Okay, so assuming that we're going to continue to store the value as double-precision, and that as such errors may accumulate, I buy that we don't want to present these errors to the user, so I agree that we need to round the values converted to strings.

Couple more thoughts though:

(1) I think these comments in the patch are slightly misleading:

 63     // It's because printing
 64     // as double-precision floating point numbers (by JavaScript's ToString())
 65     // cannot work due to numeric errors. (JavaScript uses double-precision,
 66     // though HTML5 uses single-precision.)

 72     // Round the result with 9 significant digits.
 73     // 9 because of the significant digits of IEEE 754 single-precision numbers.

I don't think this is completely accurate.  I don't believe HTML5 can be said to use single-precision (it does spec single-precision range for values parsed, but the requirement to use JS ToString would seem to implicitly favor double-precision for any operations, to avoid a precision mismatch).  Looking at the code, I'm only seeing WebCore using double precision values here – so I'm not sure this issue can really be said to be related to single-precision.  Given this, I think 9 is really just an arbitrary limit, which is not ideal.

(2) There seems to be a second problem, in that the internal value of the input element won't accurately match its string representation.  I can imagine this exposing itself in two ways.  Firstly, since rounding errors are retained in the internal value, it seems they could accumulate – if a script triggered stepUp/stepDown enough, it would seem possible that the rounding errors in value could accumulate to the point of overflowing into the 9 s.f. range.  Secondly, if there is any method allowing direct access to the internal value (or if any such interface is introduced), then the value accessed as a string would not match the value accessed as a number and then converted to string (e.g. in script code).  The problem still seems to lie in the fact that the applyStep() method is generating a value containing rounding errors (and as such is possibly failing to generate a new value that satisfies its constraints).  As such, I think the right fix is still to change applyStep(), such that this produces a suitable result.  Rounding at this stage will both prevent errors from propagating, and ensure that if the value is read directly as a double through any other means its string representation will still match the string value of the input element.

Let me suggest a possible alternate solution.  Presumably the number of decimal places we want the value rounded to is equal to the max of the number of decimal places in the base and step values.  For example, with a base of 0.1 and a step of 0.01, we never want more than 2 DP of precision to be retained.  We can easily enough calculate the number of DP of precision required to represent the base/step values based on their string length, and index('.').  You could then truncate then newValue in applyStep() by multiplying by 10^DP, rounding, and then dividing by 10^DP.

cheers,
G.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.