Bug 120038 – input[type=date] with invalid date should return empty string for value IDL attribute instead of the default value

• Status: RESOLVED
• Resolution: FIXED
• Component: Forms

[Ryosuke Niwa]

Consider merging https://chromium.googlesource.com/chromium/blink/+/cb52052e3522824fa9ffc73cb34667492d47d976

BaseDateAndTimeInputType::sanitizeValue should return an empty string if the input string is invalid.

[Ahmad Saleem]

I can see that it is not applied:

https://github.com/WebKit/WebKit/blob/4cae97e20519714f2a1d4559ceec8c94d7eb2410/Source/WebCore/html/BaseDateAndTimeInputType.cpp#L230

___

Webkit GitHub Source:

return typeMismatchFor(proposedValue) ? String() : proposedValue;

___

Blink Chromium Patch Proposed:

return typeMismatchFor(proposedValue) ? emptyString() : proposedValue;

[Ahmad Saleem]

https://github.com/WebKit/WebKit/pull/3513

[Ahmad Saleem]

NOTE - I tried doing the change in below Pull Request and noticed following:

https://github.com/WebKit/WebKit/pull/3516

1) Test Case in Chromium / Blink is outdated and you need to get updated from Blink / Chromium Github mirror or source.chromium.org

2) In the updated test case, they are using "runtimeFlags" rather than "settings in below, so this need to be tweak to run in Webkit:

internals.settings.setLangAttributeAwareFormControlUIEnabled(true);

3) Safari / Webkit fail difference tests across different infrastructure but do pass few of them as well. It could be "platform" dependent / locale dependent cases and investigating them was beyond my expertise.

4) This change only fail "test" which is within this Chromium / Blink commit, if you do change without test case, it does not fail any existing test case and it is currently still in Chromium Source Code. So it is kind of fail safe but we cannot land it without test case, so I hate to close my pull request.

Just wanted to share the information for anyone who try to attempt this in future. Thanks!

[Ahmad Saleem]

(In reply to Ahmad Saleem from comment #3)
> NOTE - I tried doing the change in below Pull Request and noticed following:
> 
> https://github.com/WebKit/WebKit/pull/3516
> 
> 1) Test Case in Chromium / Blink is outdated and you need to get updated
> from Blink / Chromium Github mirror or source.chromium.org
> 
> 2) In the updated test case, they are using "runtimeFlags" rather than
> "settings in below, so this need to be tweak to run in Webkit:
> 
> internals.settings.setLangAttributeAwareFormControlUIEnabled(true);
> 
> 3) Safari / Webkit fail difference tests across different infrastructure but
> do pass few of them as well. It could be "platform" dependent / locale
> dependent cases and investigating them was beyond my expertise.
> 
> 4) This change only fail "test" which is within this Chromium / Blink
> commit, if you do change without test case, it does not fail any existing
> test case and it is currently still in Chromium Source Code. So it is kind
> of fail safe but we cannot land it without test case, so I hate to close my
> pull request.
> 
> Just wanted to share the information for anyone who try to attempt this in
> future. Thanks!

5) In new test case, they have changed the wording for keys to "ArrowUp", which are not supported within Webkit/Github test infrastructure, so they need to be tweaked back to old test case from this "upArrow" otherwise there will be more failures and in some platform, you will get weird outputs.

e.g. on mac-wk, without (5), you will get following on sample test case:

== Up/Down keys ==
FAIL input.value should be 2012-10-29. Was 2012-09-29ArrowUp.
FAIL input.value should be 2012-08-29. Was 2012-09-29ArrowUpArrowDownArrowDown.

But if you tweak it to "upArrow" etc., you get this:

== Up/Down keys ==
FAIL input.value should be 2012-10-29. Was 2012-09-29.
FAIL input.value should be 2012-08-29. Was 2012-09-29.

[Radar WebKit Bug Importer]

<rdar://problem/99296146>

[Ahmad Saleem]

In following tests:

https://searchfox.org/wubkat/source/LayoutTests/fast/forms/date/date-editable-components/date-editable-components-keyboard-events.html

Add following:

beginTest("undefined", "2012-02-01");
UIHelper.keyDown("\t"); // -> 02/[01]/2012
UIHelper.keyDown("downArrow"); // -> 02/[31]/2012
shouldBeEqualToString('input.value', ''); // 2012-02-31 is not a valid date.

-- I don't think we need to have these events fired, but if we do, we might need to tweak below.
shouldBe("changeEventsFired", "4");
shouldBe("inputEventsFired", "4");

_________________________

Still want to fix this bug but might be something over the weekend. Unless if someone wanna do it quickly.

____

What steps will reproduce the problem?

1. Open data:text/html,<input type=date value="2013-02-01" oninput="co.innerHTML=this.value"><pre id=co></pre>

2. Change the day field from "01" to "31"

3. Observe text below the date control

^ Credits to Chrome bug.

[EWS]

Committed 263784@main (6a08e90633f7): <https://commits.webkit.org/263784@main>

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