You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Something has changed with the DatePicker control since an earlier release (1.49.0 I believe, or thereabouts). It is evident when the allowInput property is set to true, thus allowing the user to type a date, as well as being able to choose it from the dropdown calendar.
The onChange callback for the DatePicker used to be called either when a new date was picked from the calendar, or when the date input lost focus. In the latest Carbon versions, it now appears that onChange is not called when the input loses focus, unless the loss of focus is due to the user tabbing away using the keyboard; if the control loses focus by the user clicking away from it with their mouse, onChange does not get called.
This means that an up to date value of date can be missed, or invalid values (caused when the user types something illegal) are not recognised and cannot be coped with.
We cannot use onChange/onBlur from the DateInputField as a workaround. Although we can use this to detect a valid typed date, we cannot use it to detect an invalid date. If an invalid date is typed in (say, "xxxx"), in the onBlur all we will know is that the user has typed "xxxx"; however, flatpickr will have automatically cleared this date out on leaving the field, due to it being invalid, and hence the input value we have in state ("xxxx") will not match the actual text being shown in the component (empty).
Ultimately, onChange for the whole DatePicker should be the "go-to" handler for handling all new values, be they chosen from the dropdown, or typed by the user into the input field, and this is not working.
I would class this as a Sev 2 defect, because this basically stops us being able to accept manual date input from the user: the only reliable behaviour of the component is that experienced when dates are chosen from the dropdown calendar.
If you choose a date from the DatePicker dropdown you will notice that the "Date picker date" correctly shows the chosen date.
If you then enter the date input field and type in a new date, and then click into the white area of the page in order to shift focus away from the DatePicker, you will notice that the "Date input date" shows the text that was entered, but the "Date picker date" is still showing the previously chosen date". This is the defect: an up to date value of date, as typed in by the user, is missed.
By comparison though, if you enter the date input field and type in a new date but then press the TAB key to leave the control, the "Date picker date" is updated to show the new date.
It seems that onChange for the DatePicker is not being called when a free text date is entered and focus is lost due to mouse action rather than keyboard action.
Suggested Severity
Severity 2 = User cannot complete task, and/or no workaround within the user experience of a given component.
Package
@carbon/react
Browser
Firefox
Package version
1.59.0
React version
18.2.0
Description
Something has changed with the DatePicker control since an earlier release (1.49.0 I believe, or thereabouts). It is evident when the
allowInput
property is set to true, thus allowing the user to type a date, as well as being able to choose it from the dropdown calendar.The
onChange
callback for the DatePicker used to be called either when a new date was picked from the calendar, or when the date input lost focus. In the latest Carbon versions, it now appears thatonChange
is not called when the input loses focus, unless the loss of focus is due to the user tabbing away using the keyboard; if the control loses focus by the user clicking away from it with their mouse,onChange
does not get called.This means that an up to date value of date can be missed, or invalid values (caused when the user types something illegal) are not recognised and cannot be coped with.
We cannot use
onChange
/onBlur
from the DateInputField as a workaround. Although we can use this to detect a valid typed date, we cannot use it to detect an invalid date. If an invalid date is typed in (say, "xxxx"), in the onBlur all we will know is that the user has typed "xxxx"; however, flatpickr will have automatically cleared this date out on leaving the field, due to it being invalid, and hence the input value we have in state ("xxxx") will not match the actual text being shown in the component (empty).Ultimately,
onChange
for the whole DatePicker should be the "go-to" handler for handling all new values, be they chosen from the dropdown, or typed by the user into the input field, and this is not working.I would class this as a Sev 2 defect, because this basically stops us being able to accept manual date input from the user: the only reliable behaviour of the component is that experienced when dates are chosen from the dropdown calendar.
Reproduction/example
https://stackblitz.com/edit/github-sf1rjr-jgpsi5?file=src%2FApp.jsx
Steps to reproduce
If you choose a date from the DatePicker dropdown you will notice that the "Date picker date" correctly shows the chosen date.
If you then enter the date input field and type in a new date, and then click into the white area of the page in order to shift focus away from the DatePicker, you will notice that the "Date input date" shows the text that was entered, but the "Date picker date" is still showing the previously chosen date". This is the defect: an up to date value of date, as typed in by the user, is missed.
By comparison though, if you enter the date input field and type in a new date but then press the TAB key to leave the control, the "Date picker date" is updated to show the new date.
It seems that
onChange
for the DatePicker is not being called when a free text date is entered and focus is lost due to mouse action rather than keyboard action.Suggested Severity
Severity 2 = User cannot complete task, and/or no workaround within the user experience of a given component.
Application/PAL
IBM CloudPak for AIOps
Code of Conduct
The text was updated successfully, but these errors were encountered: