Bug 92370 - Change the rules for parsing floating-point number values to use finite IEEE 754 double-precision floating-point values
Summary: Change the rules for parsing floating-point number values to use finite IEEE ...
Status: RESOLVED DUPLICATE of bug 249783
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Kwang Yul Seo
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-07-26 05:45 PDT by Kwang Yul Seo
Modified: 2023-12-03 15:38 PST (History)
9 users (show)

See Also:


Attachments
Patch (1.65 KB, patch)
2012-07-26 05:46 PDT, Kwang Yul Seo
no flags Details | Formatted Diff | Diff
WIP patch (19.24 KB, patch)
2012-07-27 21:55 PDT, Kwang Yul Seo
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Kwang Yul Seo 2012-07-26 05:45:13 PDT
Remove the following FIXME comment:

// FIXME: We should use numeric_limits<double>::max for number input type.

Use std::numeric_limits<double>::max() instead of std::numeric_limits<float>::max().
Comment 1 Kwang Yul Seo 2012-07-26 05:46:35 PDT
Created attachment 154621 [details]
Patch
Comment 2 Kwang Yul Seo 2012-07-26 05:48:54 PDT
I am quite curious why there is a FIXME comment like this. The FIXME author could change float to double in a second. Any profound reason?
Comment 3 yosin 2012-07-26 18:52:41 PDT
(In reply to comment #2)
> I am quite curious why there is a FIXME comment like this. The FIXME author could change float to double in a second. Any profound reason?

Hi Kwang, thanks for picking up this FIXME.
The change is simple, but we need to update and add test cases.

To fix this FIXME, we would like to do:
 1. Update code like what you did and 
   - Change variable name to "maximum", "maximumNumber" or something unrelated to type.
   - Update comments at line 107. HTML5 spec. uses IEEE 754 double-precision floating point values.
 2. Run layout tests, especially for fast/forms/number, fast/forms/range and update them.
   - I expect some tests will be failed.
 3. Add test cases for std::numeric_limits<double>::max() into fast/forms/number and fast/forms/range
   - number-validity-state-range-overflow and number-validity-state-range-underflow
   - number-stepup-stepdown-from-renderrer, range-stepup-stepdown-from-renderrer
 4. We also need to fix float-max related FIXME in 
    - WebCore/html/NumberInputType.cpp 
    - WebCore/html/StepRange.cpp
  to make layout tests work.
 5. Make sure we have tests for maximum value and minimum value
   <input id=test type=number>
   $('test').valueAsNumber = 1.7976931348623157e308
   shouldBeEqualToString('$("test").value', "1.7976931348623157e308")
   $('test').value = "1.7976931348623157e308"
   shouldEvaluateTo('$("test").valueAsNumber', 1.7976931348623157e308)
   and so on.
Comment 4 Kwang Yul Seo 2012-07-26 18:56:17 PDT
(In reply to comment #3)
Wow. Thanks for explaining this to me. I will work on this!
Comment 5 Kwang Yul Seo 2012-07-27 21:55:05 PDT
Created attachment 155107 [details]
WIP patch
Comment 6 Kwang Yul Seo 2012-07-27 22:02:04 PDT
Comment on attachment 155107 [details]
WIP patch

View in context: https://bugs.webkit.org/attachment.cgi?id=155107&action=review

This is my work-in-progress patch. I will add more layout tests.

> Source/WebCore/html/StepRange.cpp:170
>      // Accepts erros in lower fractional part which IEEE 754 single-precision
>      // can't represent.
> -    const Decimal computedAcceptableError = acceptableError();
> +    const Decimal computedAcceptableError = acceptableSinglePrecisionError();

I am not sure what's the right behavior here. What does the HTML5 spec say here?
Comment 7 yosin 2012-07-29 19:13:56 PDT
Comment on attachment 155107 [details]
WIP patch

View in context: https://bugs.webkit.org/attachment.cgi?id=155107&action=review

> Source/WebCore/html/NumberInputType.cpp:115
> +    if (newValue < -maximumNumber) {

This condition is true only if newValue is negative infinity.
Do we really need this check? It seems call sites check finite or not.

> Source/WebCore/html/NumberInputType.cpp:-120
> -    if (newValue > floatMax) {

This condition is true only if newValue is positive infinity.
Do we really need this check? It seems call sites check finite or not.

>> Source/WebCore/html/StepRange.cpp:170
>> +    const Decimal computedAcceptableError = acceptableSinglePrecisionError();
> 
> I am not sure what's the right behavior here. What does the HTML5 spec say here?

I think using acceptableError is OK here if acceptableError calculate step / (1 << DBL_MANT_DIG)

> Source/WebCore/html/parser/HTMLParserIdioms.cpp:140
>      // Numbers are considered finite IEEE 754 single-precision floating point values.

Please remove this comment. HTML5 spec uses "double-precision floating point value" now
and section number is different from current spec's section number. HTML5 specs is still
changing, it is hard to synchronize section number in the comment and HTML5 spec.

> Source/WebCore/html/parser/HTMLParserIdioms.cpp:142
> +    if (-std::numeric_limits<double>::max() > value || value > std::numeric_limits<double>::max())

This condition expression can't be true. Because, value is finite number.
So, we don't need to have this if statement.
Comment 8 Kent Tamura 2012-07-30 19:29:40 PDT
parseToDecimalForNumberType() is used by HTMLProgressElement and HTMLMeterElement too. We need to add test cases for them.
Comment 9 Ahmad Saleem 2023-02-18 06:47:02 PST
FIXME is gone now - https://github.com/WebKit/WebKit/commit/134163e4e3101c02038c4447672158e4a2fac445

but I am not sure, if anything else is needed here or not?

@rniwa & @aditya - any input?
Comment 10 Ahmad Saleem 2023-12-03 15:38:25 PST

*** This bug has been marked as a duplicate of bug 249783 ***