Keyboard input doesn't work for InputDateType.DateTimeLocal

[SteveSandersonMS]

Although <InputDate Type="@InputDateType.DateTimeLocal" @bind-Value="@someDate" /> works great with mouse input, it's not possible to use it with keyboard input.

This is quite strange because keyboard input does work for the other date types. From experimenting with this a bit, it seems that Chromium has some weird inconsistencies in how keyboard input is handled across the specialized date/time inputs, and it particularly goes wrong for us in the case of datetime-local because of a bad interaction with Blazor's @bind mechanism.

Scenario

<EditForm Model="@this">
    <p>Date: <InputDate Type="@InputDateType.Date" @bind-Value="@someDate" /></p>
    <p>Time: <InputDate Type="@InputDateType.Time" @bind-Value="@someDate" /></p>
    <p>Month: <InputDate Type="@InputDateType.Month" @bind-Value="@someDate" /></p>
    <p>DateTimeLocal: <InputDate Type="@InputDateType.DateTimeLocal" @bind-Value="@someDate" /></p>
    <p>You entered: @someDate</p>
</EditForm>

@code {
    DateTime someDate;
}

Expected: Should be able to type arbitrary data into any of these inputs using keyboard alone
Actual: It's possible for all of them except for DateTimeLocal, which behaves erratically

For example, try to type in any complete year such as 01/01/2000. I couldn't manage it. Sometimes (depending on what's already in the input) it auto-focuses-out when I enter either the day or month part, preventing me from continuing with the input. When the input was previously untouched, I get as far as the year part, and when I type in the third digit of 2000, it weirdly resets back from 01/01/--20 to 01/01/---2. Sometimes it resets after the first keystroke. I didn't figure out any combination of keystrokes that would get the date I wanted into the input.

What's going on

I haven't investigated the full sequence of events completely, but one thing I do know: these specialized date inputs raise change events a lot more often than you'd think! Once it contains a valid entry, every subsequent keystroke raises a change, which means Blazor is constantly trying to map the partial input back to a valid System.DateTime. If .NET's representation of that partial input is not the same JavaScript supplied, then the .NET side will overwrite the DOM state with its new representation, which probably leads to the interference.

I don't fully know why this only affects datetime-local and not the others. Maybe the others are lucky in that their partial input is always legal, or maybe datetime-local is the unlucky one due to some other quirk.

Fixing it

If it's possible to find a simple fix for this that's great. Maybe it's possible to have <InputDate> listen for a different event like blur/focusout depending on the Type. Maybe some other trick in the binding internals would handle it. If it turns out there isn't a good option, we still could remove the DateTimeLocal option from the InputDateType enum and recommend people who need datetime-local should bind it to a string and then do their own parsing later.