calcite-design-system
calcite-design-system copied to clipboard
calcite-input-date-picker calendar should not change year in certain case
Reported by Beyondsoft
Instruction:
- place cursor in input box and hit backspace 1-3 times
- the calendar popover updates to weird years
- the probability that users actually want to switch from year 2021 to year 202, 20 or 2 is probably nil
- therefore the calendar popover should not change its year until a valid date is entered in the input box or the user clicked on a date inside the calendar
From Beyondsoft: 10. Click the calendar icon of date textbox. 11. Select a date and delete the date by press backspace keyboard. –key step 12. Observe. 13. Continue to delete date in date textbox by press backspace keyboard again. –key step 14. Observe. 15. Continue to delete date in date textbox by press backspace keyboard again. –key step 16. Observe.
Actual result: Step 12: It got stuck and then skipped to invalid date if deleting date in date textbox by press backspace keyboard. Step 14: It skips to another invalid date if deleting date in date textbox by press backspace keyboard again. Step 16: It displays default date value in date textbox if deleting date in date textbox by press backspace keyboard again.
Expected: The deleted value in date should be removed but the original date should not be changed in date textbox if deleting date in date textbox by press backspace keyboard.
Actual Behavior
year inside the calendar changes to 202, 20, 2
Expected Behavior
calendar should stick to year 2021
Reproduction Steps and Sample
https://codepen.io/afreitag/pen/KKXaYQa?editors=1010
Relevant Info
Reproducible version: @esri/[email protected]
- [ ] CDN
- [ ] NPM package
@AdelheidF Is the ask here that the calendar shouldn't update unless at least a 4-digit year is typed? Technically 202
, 20
and 2
are all valid years, so it sounds like the ask is to only update the calendar when a full 4 digits are typed, otherwise you'll prevent someone from typing in valid single, double and triple digit years (in number format as opposed to padded zero string representations).
Yes, I'd prefer that we ask the user to always enter a 4 digit year, otherwise there are too many options of what it could mean.
Installed and assigned for verification.
verified with beta.98. Nice!