Lukas Tyla

> > Of the options you listed LukasTy, it seems like the best option is to not auto-close the modal and require to click outside or OK in the action...

> Regarding the auto-closing strategy, there seem to be a few small cases that are not covered. For example, in the following sandbox, it won't auto-close if I select minutes...

Am I missing something, but isn't the described behavior the responsibility of the `placeholder` attribute/prop? 🤔 Here is an [example codesandbox](https://codesandbox.io/s/placeholder-mui-v5-xtnzz5). But this reminds me of another concern I had...

During the grooming, we decided on the following idea to experiment with its feasibility in order to achieve similar UX (behavior) to existing (v5) pickers: - while `value` is empty...

We can't compare behaviors of your mentioned library and the newer examples showcased by Alex, because the new version no longer uses a popover disabling scrolling (dialog), hence, it naturally...

Based on the following recording, I don't think there is anything to improve here as far as out-of-the-box experience goes. The popper seems to be correctly flipped to the top...

@sohaibnajjar Could you explain what are you trying to achieve by specifying `disabled` only on the rendered `input`? Doing this only the rendered input is aware, that it should be...

Thank you for opening this issue! Please refer to the [API documentation](https://mui.com/x/api/date-pickers/mobile-date-picker/#:~:text=for%20your%20format.-,disableOpenPicker,-bool) or JSDoc in IDE for a prop description. The current v5 release, has the following description for this...

Also correctly handle the `clearable` behavior with the removal of `readonly` mobile Pickers. https://github.com/mui/mui-x/issues/10842#issuecomment-1870298882

We agreed to unify the field/input behavior on Mobile Pickers allowing editing in them just like [React Spectrum does](https://react-spectrum.adobe.com/react-spectrum/DatePicker.html). This would be a behavioral breaking change, thus, we are keeping...