[pickers] onAccept is fired before entering the complete date when using the input field

[auloin]

Steps to reproduce

Steps:

1. Open this link to live example: https://codesandbox.io/p/sandbox/upbeat-pasteur-8vfjyw
2. Enter a date via the input field
3. Open the console and notice that dates are being accepted before completely entering the last date part

Current behavior

onAccept is fired as soon as the user start filling in the last date part.

 Date accepted 2026-10-02T08:01:00.000Z
 Date accepted 2026-10-02T08:12:00.000Z 

I want to enter 2026-10-02 08:12 but the date is accepted as soon as I entered the first minutes digit. This contrast with the picker alternative where I actually need to click ok before onAccept is fired.

Expected behavior

I expect onAccept to always behave similarly to the picker. Ideally it should only fire after the user gives the go.

Context

My use case is to make a request after the user has selected a date. The date field is part of a "dialog" that closes after the user picked a date. Since onAccept is fired before the completion of the entire field, my approach is now a mess of a UX.

In v6 (version I'm upgrading from), I'd just use onBlur on the textfield. I don't think this approach works now.

From a developer perspective, the current behavior is a bit ambiguous as it doesn't wait for a clear signal from the user, which the picker does. If I want to make this work, I'd need to detect onAccept from the picker and onAccept from the imput field. In the second case I'd also need to somehow decide if the user is still typing...

Solutions have been discussed in #8375. I've hesitated commenting there instead of opening a new issue but #8375 can be considered completed?

Your environment

npx @mui/envinfo

  Don't forget to mention which browser you used.
  Output from `npx @mui/envinfo` goes here.

Search keywords: onAccept

[michelengelen]

Hey @auloin I appreciate you taking the time to open an issue here. I can understand that this might be a bit of a bad situation you are in. The explanation why we did it like this is to allow for the user to enter a time without the need to add padded zeroes. This is the same behavior as the native time input. The main difference is that we additionally call the onAccept callback (which the native input does not have) for every valid time being entered. For this to work we would need to pass a new property into the context parameter, maybe something like source: 'field' | 'picker' @LukasTy?

For your use case it might make the most sense to listen for the blur event on the field for keyboard input and have a similar onAccept handler for the popover. This is currently a bit wonky, but there is a PR open to fix the blur events firing during section shift: #19825

In the second case I'd also need to somehow decide if the user is still typing...

Could you please also explain what you mean with that?

[auloin]

Thanks for considering this issue and for clarifying the behaviour @michelengelen.

I'm happy to go back to using onBlur. I've a couple of questions:

1. Will onAccept still fire? If so it'd indeed be good to have a context so we can ignore the event based on the source.
2. Or is it possible to listen to onClick of the accept (OK) button?

In the second case I'd also need to somehow decide if the user is still typing...

Could you please also explain what you mean with that?

Just exploring some ways to fix this on my side and the biggest issue is that I can't tell for sure if the user is still typing or not. Because the obvious patch would be to debounce onAccept, but this can still fail for some (slow typing) users.

[LukasTy]

@michelengelen I like your idea. Adding a context field to signal what caused an onAccept to fire could help users ignore calls fired from the field and debounce them, or use the onBlur whenever that is fixed. 👍
I agree, that currently there is a lack of elegance if you wish to rely on the onAccept callback.

Or, alternatively, we can consider not calling onAccept on field changes at all, especially given that this behavior is not even documented in the lifecycle page. 🤷 🤔

[michelengelen]

Or, alternatively, we can consider not calling onAccept on field changes at all, especially given that this behavior is not even documented in the lifecycle page. 🤷 🤔

Yeah, I would honestly go for this "solution" out of 2 reasons:

1. It is not documented
2. 'onAccept' is contextually wrong on field input:

• it is impossible to determine the exact point when a user has stopped and is ready to 'accept' the changes he made
• 'onAccept' is contextually tied (in wording) to the 'accept' button

So my suggestion: once the blur PR is merged we remove the calls to 'onAccept' during keyboard input and rely on 'onBlur' for such cases.

WDYT @LukasTy and @auloin?

[LukasTy]

That sounds great to me. 👍
Avoids confusion, even though it is a BC, but I'd argue that it could be delivered within a minor, since it's already buggy, not documented, and if onBlur is fixed, can be replicated. 👍

[tkall-encora]

I have a similar issue but with the DatePicker. It triggers the onAccept (tried with onChange with same results) as soon as the first digit of the year is pressed.

I got able to solve it by using the second parameter of the onChange with the validation. https://mui.com/x/react-date-pickers/lifecycle/#only-update-for-valid-values

[github-actions]

This issue has been closed. If you have a similar problem but not exactly the same, please open a new issue.
Now, if you have additional information related to this issue or things that could help future readers, feel free to leave a comment.

[auloin]

Thanks for making the changes @michelengelen! I've noticed that the docs mention 'picker' as value of the onAccept context source, instead of 'view'. I've submitted a PR to fix it: #20465.

Here's a snippet how I'm now solving my challenge if anyone is interested:

export default function BasicDateTimePicker() {
  const inputRef = React.useRef(null);

  const onAccept = (value, context) => {
    if (context?.source === "view") console.log("Accepted from view", value);
  };

  const onBlur = () => {
    if (inputRef?.current) {
      // run validation, e.g., using date-fns isValid
      console.log("Blur", inputRef.current.value);
    }
  };
  return (
    <LocalizationProvider dateAdapter={AdapterDayjs}>
      <DemoContainer components={["DateTimePicker"]}>
        <DateTimePicker
          ampm={false}
          label="Basic date time picker"
          onAccept={onAccept}
          slotProps={{
            textField: { onBlur: onBlur },
          }}
          inputRef={inputRef}
        />
      </DemoContainer>
    </LocalizationProvider>
  );
}

(This is building on the reproducing example: https://codesandbox.io/p/sandbox/upbeat-pasteur-8vfjyw)