[Date Time Picker] Calls onChange(null) on ClickAway during edit

[BGehrels]

Affected Versions:

• 5.0.0-alpha.68
• Not affected: 5.0.0-alpha.67

How to reproduce:

The following description refers to MUIs component example page because it is the easiest way to describe the bad behaviour. The underlying issue is of course more or less independent of the example in the docs.

• Go to https://mui.com/components/date-time-picker/#basic-usage
• You'll see a "Basic usage" Headline and pre-filled DateTime Input field
• Click the calender Icon in the Input field
• Choose a different day of the same month
• You will see that the Text in the input field adapts to the new date you just chose
• Click some piece of background page whitespace far away from the Input field and the datepicker (ClickAway)

Expected Behaviour:

• The date picker will close
• The date field won't change

Actual Behaviour:

• The date picker will close
• The date field changes back to the initial value it had during page load

Why:

• When you click away, The DateTimePicker component calls onChange(null). It did not do sol in versions <= 5.0.0-alpha.67

[Ostro]

Hi @BGehrels, i ran into this bug few days ago, I might have found the cause

@Ashish2097 : https://github.com/mui/material-ui/blob/master/packages/mui-lab/src/internal/pickers/hooks/usePickerState.ts#L99
onDismiss is fired when the modal is closed, but the initalDate is never updated when you change the date via the input.
Changing from initialDate to draftState.committed fix this issue.

This being said, I not quite sure about the difference between draftState draft and commited. initDraftableDate function set both with the same value tho.

[hamquicken]

I have ran into this before as well.

Specifically, this can occur even if you have the auto-close on dateSelect. Specifically, if you select a different year with the header at the top of the datePicker, the day that was currently selected gets auto-selected for the new year (which prevents you from selecting it yourself) and therefore makes click-away the obvious way of 'selecting' the new date. But, as mentioned in this thread, clicking away fires onChange with whatever the initial value was was set to (often null if unfilled before), even if other onChange events already updated the 'value' prop being passed in to the DatePicker.

This could be solved either by never calling onChange when closing (as any date selection should have already fired onChange and therefore updated the relevant state/value), or by having close call onChange with the right date value.

[BGehrels]

@flaviendelangle @mnajdova Shall i reopen this bug at the https://github.com/mui/mui-x repositories issue tracking now that mui/material-ui#31093 has been closed or how do we proceed here?

[flaviendelangle]

@BGehrels I transfered the issue 👍
Feel free to open an equivalent of mui/material-ui#31093 here
Otherwise, I will try to do it when I will have time