1945333 - Incorrect Parsing of Floating Point Values in HTML Attributes

Status: UNCONFIRMED

(Core :: DOM: Forms, defect)

Description

[sbender]

Attachment: number-attributes-test.html

Steps to reproduce:

Write an HTML element that has a floating point attribute:
<input type="number" min="-1." max="10." value="5.">
Include a number with an ending decimal point in the attribute values, as shown above.

Actual results:

The values "-1.", "10.", and "5." are considered valid and are parsed to "-1", "10", and "5" respectively

Expected results:

The values "-1.", "10.", and "5." should be considered invalid according to the specifications.

https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#floating-point-numbers

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Forms' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Peter Van der Beken [:peterv]]

Adam worked on similar issues in the past, any idea what's going wrong here? I don't immediately find a wpt for this :-/.

Comment 3

[Adam Vandolder [:avandolder]]

The issue appears to be that we are using our localized decimal parser when value/max/min are set directly as attributes, which does not follow the spec's "valid floating-point number" rules, unlike when they are set as fields - in which case we sanitize the values.

I know Emilio has worked on number sanitization before. I'm not sure if the best solution here would be to sanitize the attributes when they are set, or if instead the parser that is being used can be changed.

Comment 4

[Emilio Cobos Álvarez (:emilio)]

(In reply to Adam Vandolder [:avandolder] from comment #3)

The issue appears to be that we are using our localized decimal parser when value/max/min are set directly as attributes, which does not follow the spec's "valid floating-point number" rules, unlike when they are set as fields - in which case we sanitize the values.

Yeah, so much like here, I think we should not allow the localization code to go around for these.

Probably easiest fix would be to add a bool aAllowLocalized or so to ConvertStringToNumber, and bail from NumberInputType::ConvertStringToNumber when false. Adam, do you have cycles to make that change? That way we can also remove the special-case linked there.