[pickers] Datepicker rendered without the button in test environment

[mor-stampli]

Duplicates

• I have searched the existing issues

Steps to reproduce 🕹

Link to live example:

Steps:

Current behavior 😯

I am running an app that uses MUI version 5
@mui/x-data-grid-pro: 5.7.0

i have very weird behavior.

1. instance that running chrome via macOs.
   • real pre prod env.
2. instance running chrome via Ubuntu (chrome runs from terminal via "sudo google-chrome-stable --no-sandbox")

• automation tests env.

first instance works great as expected.
for some reason,
DatePicker on the second instance instance is rendered with a different JSX.
picker calendar button is not rendered at all.

is there any special case for this environment ?
am i missing something?

Screen.Recording.2023-11-02.at.1.27.03.PM.mov

Expected behavior 🤔

i expect the DatePicker to rendered with the calendar picker icon button in all environments.

Context 🔦

No response

Your environment 🌎

npx @mui/envinfo

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

Search keywords:

[LukasTy]

Hello @mor-stampli
It looks like you might have a problem with the Chrome launched this way not having the necessary pointerPrecision.
Could you please read this documentation section, apply the change and double-check if it fixes your problem?

P.S. We had the same issue on our end and have specified the necessary flag to avoid this problem.

mui-x/test/karma.conf.js

Line 94 in 4295a7f

'--blink-settings=primaryPointerType=4',

[mor-stampli]

@LukasTy thanks
your link with the suggestion solve the issue :)

[mor-stampli]

Hi @LukasTy ,
the solution is actually working when we run it directly from the local environment terminal,
but we also need to be able to run it via automation server.

could you please check if there is anything else we need in order to make it work ?

here you can see the code we have running ->

[LukasTy]

@mor-stampli In the microsoft/playwright#7769 (comment) I've mentioned that this setting needs to be passed via a flag, maybe there is an option in your used API to addFlags instead? 🤔
I'm pretty sure that it's just a matter of the flag not being activated given the current way of setting it. 🤔

[dgodongm]

@LukasTy @zannager I appreciate a workaround being offered, but doesn't this point to an issue with the MUI DatePicker?

[LukasTy]

@dgodongm Why do you consider it an issue?
It is a limitation of the testing environment that can be remedied by providing a different desktopModeMediaQuery prop value in tests or making the test environment behavior closer to the "desktop" one (with a precise pointer). 🤔

[dgodongm]

@LukasTy Isn't it an issue that the DatePicker shows the mobile experience on a desktop environment? The workaround is also very non-intuitive and hard to discover. While the scenario might be unlikely to directly impact end-users, it's a common scenario for test automation.

[LukasTy]

Isn't it an issue that the DatePicker shows the mobile experience on a desktop environment? The workaround is also very non-intuitive and hard to discover. While the scenario might be unlikely to directly impact end-users, it's a common scenario for test automation.

I'm not saying it is ideal, but the current default value of the prop controlling the toggle feels versatile, albeit slightly problematic. 🤔
I don't think that relying on some arbitrary width or height would make more sense. 🤔

@dgodongm Given that we have #10039, could you explore the suggested updated media query (@media (hover: hover) and (pointer: fine)) to see if it fixes the behavior on headless browsers in CI environment?
I wouldn't mind updating the default to it if it fixes CI and certain cases of improper reporting on devices. 🙈

[dgodongm]

@LukasTy I was able to workaround issue via the Chrome pointer setting (specifically using the Cypress config setting advised here).
If the media queries are not reliable on certain devices/environments, then perhaps there's not an obvious "fix". In the headless Chrome on Linux case, would this then not be a Chrome "bug"?

I'd still argue that MUI's DatePicker is effectively a black box and the MUI documentation specifies certain behavior for mobile vs desktop. If there are limitations/quirks in certain cases, it'd be great if these could be documented along with possible workarounds (rather than living only in git issues). Thx for the help.

[LukasTy]

@dgodongm Were you able to discover this section in the docs? 🤔

[dgodongm]

@LukasTy This is great! Somehow I missed that in reviewing the DatePicker docs and it didn't come up when searching for solutions. The latter is probably my not choosing the right search terms. Perhaps the help doc could mention the symptoms of the headless browser scenario? Thx

[LukasTy]

@dgodongm Thank you for your suggestion. 👍

P.S. I've tested the updated media query on headless chrome to confirm that it wouldn't change anything. 😉