Hi Team, While going through Blink's commit, I came across another potential merge: Blink - https://src.chromium.org/viewvc/blink?view=revision&revision=171834 WebKit Source - https://searchfox.org/wubkat/source/Source/WebCore/platform/text/PlatformLocale.cpp#300 I haven't checked Web-Spec but I think we can have a quick check. Thanks!
All tests pass here https://wpt.fyi/results/html/semantics/forms/the-input-element/number.html?label=master&label=experimental&aligned&view=subtest&q=input But that doesn't mean it covers the full extent of the spec. Spec https://html.spec.whatwg.org/multipage/input.html#number-state-(type=number) > The value sanitization algorithm is as follows: If the value of the element is not a valid floating-point number, then set it to the empty string instead. Links to an algorithm to convert from string to number. https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-floating-point-number > Step 6 Skip ASCII whitespace within input given position. links to https://infra.spec.whatwg.org/#skip-ascii-whitespace > To skip ASCII whitespace within a string input given a position variable position, collect a sequence of code points that are ASCII whitespace from input given position. The collected code points are not used, but position is still updated. And ASCII whitespace means: https://infra.spec.whatwg.org/#ascii-whitespace > ASCII whitespace is U+0009 TAB, U+000A LF, U+000C FF, U+000D CR, or U+0020 SPACE.
to Note that the current code is using. String input = localized.stripWhiteSpace(); https://searchfox.org/wubkat/source/Source/WebCore/platform/text/PlatformLocale.cpp#300 which is https://searchfox.org/wubkat/source/Source/WTF/wtf/text/WTFString.cpp#160 String String::stripWhiteSpace() const { // FIXME: Should this function, and the many others like it, be inlined? // FIXME: This function needs a new name. For one thing, "whitespace" is a single // word so the "s" should be lowercase. For another, it's not clear from this name // that the function uses the Unicode definition of whitespace. Most WebKit callers // don't want that and eventually we should consider deleting this. return m_impl ? m_impl->stripWhiteSpace() : String { }; } https://searchfox.org/wubkat/source/Source/WTF/wtf/text/StringImpl.cpp#744 Ref<StringImpl> StringImpl::stripWhiteSpace() { return stripMatchedCharacters(isSpaceOrNewline); } https://searchfox.org/wubkat/source/Source/WTF/wtf/text/StringImpl.cpp#717 and inline bool isSpaceOrNewline(UChar32 character) { // Use isASCIISpace() for all Latin-1 characters. This will include newlines, which aren't included in Unicode DirWS. return isLatin1(character) ? isASCIISpace(character) : u_charDirection(character) == U_WHITE_SPACE_NEUTRAL; }
<rdar://problem/104453204>
Just to add, we fail the attached test with following output while run on WebKit ToT using Webkit Testrunner: should skip spaces from user input number On success, you will see a series of "PASS" messages, followed by "TEST COMPLETE". FAIL input.valueAsNumber should be 123456. Was NaN. FAIL input.value should be 123456. Was . PASS successfullyParsed is true Some tests failed. TEST COMPLETE ^ This is similar to Firefox Nightly 118 while Chrome Canary 118 passes this test.
Changing to: auto input = localized.removeCharacters([](auto character) { return isUnicodeCompatibleASCIIWhitespace(character); }); Fixes this bug and make us pass this test case. @Anne - any input before I do PR?
There's two different things here, right? There's parsing the value attribute of the input element correctly and there's dealing with end user input. I would expect that we don't have bugs for the former and the Chromium bug confirms this is about the latter and therefore not covered by WPT. For the latter however if we decide we want to ignore whitespace in the input (and that is probably a decision that Aditya should make a call on for Apple platforms and potentially coordinate on internally) we would want to ignore more than just ASCII whitespace. We'd want to ignore all Unicode whitespace code points. Hope that helps!
(In reply to Anne van Kesteren from comment #6) > There's two different things here, right? There's parsing the value > attribute of the input element correctly and there's dealing with end user > input. > > I would expect that we don't have bugs for the former and the Chromium bug > confirms this is about the latter and therefore not covered by WPT. > > For the latter however if we decide we want to ignore whitespace in the > input (and that is probably a decision that Aditya should make a call on for > Apple platforms and potentially coordinate on internally) we would want to > ignore more than just ASCII whitespace. We'd want to ignore all Unicode > whitespace code points. > > Hope that helps! Thanks @Anne. Let's wait for Aditya's input. :-)