Entering hour/minute in DatePicker with timePickerProps almost impossible

[gjvoosten]

Environment

• Package version(s): @blueprintjs/datetime: 3.11.0 (and @blueprintjs/core: 3.17.1)
• Browser and OS versions: any

Steps to reproduce

1. Go to the DateInput example: https://blueprintjs.com/docs/#datetime/dateinput

2. Disable Close on selection

3. Set Date format to YYYY-MM-DD HH:mm:ss (moment)

4. Set Time precision to Minute

5. Click in the date/time input

6. Click in the hour input

7. Try to delete the current hour value by repeatedly using Backspace or Delete → doesn't work, one digit always remains

8. Still in the hour input, press the Home key, then Delete → nothing is deleted, but the cursor is now at the end

9. Still in the hour input, press the Home key, then 0 (zero) → nothing is entered, but the cursor is now at the end

10. Still in the hour input, press Ctrl-A (select all), then 9 → hour changes to 9

11. Now try to put 23 in the hour input; almost impossible unless you use Ctrl-A to select all first

12. Click at the beginning of the minute input

13. Press Delete → first digit of minute becomes 0 (zero), cursor goes to the end of the input

14. Press Backspace → last digit of minute also becomes 0 (zero); note that this is different from the hour input: in the minute input, pressing End then Backspace repeatedly will end up with a value of 00, yet in the hour input, pressing End then Backspace repeatedly will not end up with 0, but with whatever value the first digit in the hour input had (e.g. if you started with 23 it will be 2, if you started with 9 it will be 9)

15. Still in the minute input, press Home then try to enter 23 → after the 2 the value is still 00 but the cursor jumps to the end, after the 3 the value becomes 03

etc.

Actual behavior

The actual behaviour is unusable. Some of it was introduced through #3581 .
The behaviour with @blueprintjs/datetime: 3.9.0 was slightly more usable, yet also not great.

Expected behavior

It really shouldn't be this difficult to enter a time in the DatePicker. My feeling is that the hour and minute inputs try to be far too clever (and behave differently to boot), which violates the principle of least surprise and requires a lot of trial and error from the user to actually enter a time.

[adidahiya]

Everything works fine if you highlight the numbers first and then start typing, but yes, I agree with you that there is a bug where you cannot delete all the numbers in the input.

What's happening is that the component tries to validate that the current value is a valid hour / minute on every change. We can either change the behavior so that:

1. this validation only happens after the input is blurred, no matter how the change was triggered
2. this validation only happens when the input contents are highlighted, but it happens immediately (as it does now).

Either way, we'd need a corresponding visual indicator (intent={Intent.Danger}) that the user's update was rejected if it's an invalid hour. We should also consider if we want to allow typing more than 2 digits (as suggested in #3719).

[gjvoosten]

@adidahiya I'd prefer to only validate on blur. Note that 3.9.0 (which I'm still using, as even 3.13.0 is not a whole lot better in this respect) does something along those lines, and when the input is invalid, reverts to the previous value. That's fine by me, but if you want to alert the user to their invalid input instead, highlighting the input field visually is probably most usable.

[gjvoosten]

Thanks @adidahiya !