New MUIv5 Datepicker does not stay on screen as well as the old Datepicker when using toolbar option

[georgesglynn]

Duplicates

• [X] I have searched the existing issues

Latest version

• [X] I have tested the latest version

Steps to reproduce 🕹

Link to live example: https://codesandbox.io/s/mui-x-issue-template-datepicker-with-toolbar-falls-off-screen-uvqrec

Steps:

1. Go to live example and scroll on the rendered demo, you'll see the datepicker fall off the screen quite a bit before it finally renders on top.
2. Disable the toolbar (uncomment/comment option added for you in demo)
3. You'll see the datepicker stay on the screen and swap to render on top when it is supposed to

Current behavior 😯

When toolbar is enabled in the new Datepicker, the calendar will fall off the screen before it begins to render the calendar above the text input.

Expected behavior 🤔

When toolbar is enabled in the new Datepicker, operate just as it did when toolbar was disabled. As soon the datepicker begins to fall off the screen, render it on top of the text input.

Context 🔦

Improve the UX for my users.

Your environment 🌎

npx @mui/envinfo

  System:
    OS: macOS 12.6
  Binaries:
    Node: 16.14.2 - /usr/local/bin/node
    Yarn: Not Found
    npm: 8.19.2 - /usr/local/bin/npm
  Browsers:
    Chrome: 109.0.5414.119
    Edge: Not Found
    Firefox: 109.0
    Safari: 16.0
  npmPackages:
    @emotion/react: 11.10.5 => 11.10.5 
    @emotion/styled: 11.10.5 => 11.10.5 
    @mui/base:  5.0.0-alpha.113 
    @mui/core-downloads-tracker:  5.11.6 
    @mui/icons-material: 5.11.0 => 5.11.0 
    @mui/material: 5.11.4 => 5.11.4 
    @mui/private-theming:  5.11.2 
    @mui/styled-engine:  5.11.0 
    @mui/styles: 5.11.2 => 5.11.2 
    @mui/system:  5.11.5 
    @mui/types:  7.2.3 
    @mui/utils:  5.11.2 
    @mui/x-data-grid:  5.17.18 
    @mui/x-data-grid-pro: 5.17.18 => 5.17.18 
    @mui/x-date-pickers: 5.0.13 => 5.0.13 
    @mui/x-date-pickers-pro: 5.0.13 => 5.0.13 
    @mui/x-license-pro: 5.17.12 => 5.17.12 
    @types/react:  17.0.53 
    react: 17.0.2 => 17.0.2 
    react-dom: 17.0.2 => 17.0.2 
    typescript:  4.9.4

Order ID 💳 (optional)

EP522468 - this is likely an internal purchase order ID, I don't have access to the MUI Order ID at this time

[alexfauquette]

The behavior is the same in v6 (codesandbox)

But I do not think it's a bug, it's a compromise due to lack of space:

• The default behavior is to put the modal at the bottom
• If there is not enough space to display it bellows, but enough to display it at the top, the modal moves to the top
• If there is not enough space at the top and bottom, the modal stays at the top

Is this explanation ok for you?

https://user-images.githubusercontent.com/45398769/216964934-2bde9a81-b729-43e6-8075-913b9f47b128.mp4

[georgesglynn]

Hey Alex! Thanks for responding to my issue!!

What you've sent over makes sense. Let me know if this makes any sense:

From my perspective this is a bug because it impacts the usability of this component for the end users. The datepickers in v4 worked differently and hence did not have this bug.

Regardless of the spacing issue you called out, in the v4 version of datepicker it would shift the whole calendar picker up so that the entire calendar picker was on the screen always. If it had to it would be pushed up on top of the text input, which is totally fine from a usability standpoint since you should only be concerned with interacting with the calendar at that moment.

The calendar picker falling off the screen in these scenarios makes this version of the calendar picker unusable in our case. We'll have to adjust to using the MobileDatePicker everywhere throughout our app to work around this for the time being.

Let me know if you need me to explain this any better!!

Thanks again!

George

[alexfauquette]

Maybe it would be clearer if you provide an example of the v4 behavior you want.

Here is a demo with v5 and v4 pickers next to each over, and they have the same behavior

https://codesandbox.io/s/mui-x-issue-template-datepicker-with-toolbar-falls-off-screen-forked-o7bzwe?file=/src/App.tsx

[georgesglynn]

Ahh I see. Maybe the disconnect is that I was misspeaking when I said v4. The pickers our project are used to are the old old pickers here when they were a separate module: https://material-ui-pickers.dev/demo/datepicker

Look in this screenshot how the picker adjusted so that it's always entirely on the screen, even if it has to go over the text input:

You can see how it works on that link I sent above.

[LukasTy]

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 works differently when scrolling is unavailable. Given this case, there is technically not much difference between material-ui-pickers example you showcased and the MobileDatePicker component you mentioned that you consider using instead. They both behave more or less the same, just differ in visual presentation, while the new Desktop variant works differently, still allowing scrolling behaviour, which is somewhat more natural for Desktop environments.

The problem you are showcasing is somewhat interesting, but is just a result of the layout. The picker popper does get visually "cut off" when it no longer fits at the top, but at the same time the page height is increased and the user can scroll to the bottom of the calendar.

If you are concerned with smaller screens, that's the main reason why the wrapping DatePicker exists, controlling, which (Mobile or Desktop) picker is actually rendered depending on the met criteria. Desktop users are less often constrained by viewport size and it should very rarely be a problem using the DesktopDatePicker, whereas on touch devices, the viewport could be considerably smaller, and rendering a fixed MobileDatePicker should cater to such users better. 🤔

[LukasTy]

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 of the input when it no longer fits in the viewport. The behavior seems to be the same and correct regardless of whether the toolbar is present or not. If need be, the popper behavior can be changed using modifiers.

If anyone sees an issue with the behavior that we provide, please feel free to reopen this issue or create a new one.

https://github.com/mui/mui-x/assets/4941090/d9acf5cb-e289-40a6-a9f9-5fde72acd68f