[BUG] - Keyboard input in v15.1.4 is difficult to use

[cjohnston-ey]

Describe the bug
I believe changes made to fix #49 made it more difficult to enter time with the keyboard.

To Reproduce
Stackblitz: https://stackblitz.com/github/cjohnston-nuvalence/ngx-mat-timepicker-keyboard

If I want to enter a time with "35" as the minutes by the keyboard, for example, there are a couple of ways to do it and each has issues.

All scenarios assume a timepicker with [enableKeyboardInput]="true" set.

Scenario 1:

1. Click the input field to open the clicker
2. The hours field is selected by default
3. Tab to move the keyboard entry to the minutes field or click at the end of the minutes input field
4. The cursor is at the end of the input field
5. Type "35"
6. The minutes input field contains "0035" and the control's time setting is not changed

Scenario 2:

1. Click the input field to open the clicker
2. The hours field is selected by default
3. Click at the beginning of the minutes input field
4. The cursor is at the beginning of the input field
5. Type "35"
6. The minutes input field changes to "30" after entering the 3 and the 5 is ignored

Scenario 3:

1. Click the input field to open the clicker
2. The hours field is selected by default
3. Click at the middle of the minutes input field
4. The cursor is between the 0s in the input field
5. Type "35"
6. The minutes input field changes to "03" after entering the 3 and the 5 is ignored

Expected behavior
In all scenarios the minutes should be set as 35

Desktop (if execution):

• OS: MacOS
• Browser: chrome, safari

** Versions

• ngx-mat-timepicker version [15.1.4]
• @angular/core version [15.1.0]
• @angular/material version [15.1.0]
• typescript version [4.9.4]

[tonysamperi]

So now I need to revert what I did for #49

[cjohnston-ey]

The changes for #49 are still important, but it seems like those changes uncovered some other time parsing oddities.

[tonysamperi]

@cjohnston-nuvalence I just published the revert for that fix.
You're still convinced it's a parsing issue, but it's not.
Here we're trying to control how user types values inside the inputs.
Basically you wanted to prevent Invalid Datetime caused ignorant users that type before "00" without deleting.
I'll try to see a clean way of checking how the input is changed (before or after existing value), but for now it's better to go back the way it was.

[tonysamperi]

This is solved by v 15.1.5

[tonysamperi]

Hi @cjohnston-nuvalence can you please check how the input at the bottom of the page behaves?

https://stackblitz.com/edit/ts-angular-13-web-container-starter

[cjohnston-ey]

That behavior looks pretty good except in one case.

1. Enter "00" in the input to simulate the initial value
2. Move the cursor to the beginning of the field
3. Type something like "15"

After the "1" is entered, the value is set to "10" and cursor is placed at the end of the input which ends up ignoring the "5"

[tonysamperi]

@cjohnston-nuvalence hehehe I came across the same behaviour...
I have no idea why it goes havoc with zeroes...
But you know the most interesting fact? It only behaves this way with angular!
I'll add a simple js version of this in the same blitz and you'll see that it doesn't happen...
I guess that is something related to the lifecycle...I'll do some experiments with zone and see if I can improve...
If I get something stable I can integrate the code in the lib and have the improved behaviour...

EDIT
Actually it's not the zeroes...but yet...try the normal when you have time...

REEDIT
I did another behaviour change in the Angular one...since you can't basically set the caret at position 1 after typing, why not deleting the existing value completely?
This allows the user to start typing a new value without incurring in the "Invalid Datetime" error.
I think I'll made some kind of poll on the demo site...