Bug 268542 – Parsing of floating-point number values in attributes should allow leading ascii whitespace, plus sign, and trailing junk

• Component: DOM
• Status: RESOLVED FIXED

[Thomas Broyer]

Created attachment 469649 [details]
Test case reduction

Per HTML rules for parsing floating-point values [1], leading ASCII whitespace, plus (+) sign, and trailing junk (similar to integers).

This is not the case for the progress element's max and value attributes, and meter element's value, min, max, low, high, and optimum attributes, that are all defined to use these rules [2,3,4].

Reproduced in Epiphany 6.0 and WebKitGTK MiniBrowser (same user agent): Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.0 Safari/605.1.15

These are not tested by Web Platform Tests because meter attributes have a "custom getter", and the progress element's max attribute is of type "limited double" which is not implemented in the test harness (reflection.js).

[1] https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#rules-for-parsing-floating-point-number-values
[2] https://html.spec.whatwg.org/multipage/form-elements.html#the-progress-element:rules-for-parsing-floating-point-number-values
[3] https://html.spec.whatwg.org/multipage/form-elements.html#the-progress-element:rules-for-parsing-floating-point-number-values-2
[4] https://html.spec.whatwg.org/multipage/form-elements.html#the-meter-element:rules-for-parsing-floating-point-number-values

[Ahmad Saleem]

*** Safari 17.3 ***

progress.value (" 50"): 0
progress.max ("100junk"): 1

meter.min ("\t1"): 0
meter.low ("+2"): 0
meter.optimum ("\n3"): 0.5
meter.value ("\r4"): 0
meter.high ("4.5.6"): 1
meter.max ("\f7"): 1

*** Chrome Canary 123 ***

progress.value (" 50"): 0
progress.max ("100junk"): 1

meter.min ("\t1"): 0
meter.low ("+2"): 0
meter.optimum ("\n3"): 0.5
meter.value ("\r4"): 0
meter.high ("4.5.6"): 1
meter.max ("\f7"): 1

*** Firefox Nightly 124 ***

progress.value (" 50"): 1
progress.max ("100junk"): 1

meter.min ("\t1"): 1
meter.low ("+2"): 2
meter.optimum ("\n3"): 3
meter.value ("\r4"): 4
meter.high ("4.5.6"): 7
meter.max ("\f7"): 7

[Thomas Broyer]

This Pull Request to Web Platform Tests would test this for the progress element's max value: https://github.com/web-platform-tests/wpt/pull/44355

[sideshowbarker]

Pull request: https://github.com/WebKit/WebKit/pull/23719

[Anne van Kesteren]

I had trouble reading comment 0, but it seems the problem is that due to lack of test coverage we never aligned parsing for the attributes enumerated in comment 0 with the HTML standard.

We have a larger problem with parsing floating-point values which is that we handle whitespace incorrectly (this is not covered by WPT and the same overall bug is applicable to Chromium), as tracked by bug 255467.

It seems Mike discovered this, but we might need a different approach towards fixing the issue.

[Thomas Broyer]

(In reply to Anne van Kesteren from comment #4)
> I had trouble reading comment 0, 

Ah sorry, the first sentence was incomplete and should have read:

> Per HTML rules for parsing floating-point values [1], leading ASCII whitespace, plus (+) sign, and trailing junk **should be ignored** (similar to integers).

Hope that makes it a bit clearer.

[Radar WebKit Bug Importer]

<rdar://problem/122533439>

[EWS]

Committed 278541@main (806925c1274e): <https://commits.webkit.org/278541@main>

Reviewed commits have been landed. Closing PR #23719 and removing active labels.