Date picker unexpectedly appears above dialog overlay

[Chris3y]

Description

The datepicker has a higher z-index than the dialog overlay (probably to ensure dates inside dialog always show) but causes the unexpected behavior in this situation. I.e. The date picker is above the darkened overlay.

Reproduction

https://stackblitz.com/edit/parsium-carbon-starter-ejsyyt?file=src%2FApp.tsx

Steps to reproduce

In sandbox,

• use the datepicker to pick a new date value
• press tab, to trigger the field's onBlur

JIRA ticket numbers (Sage only)

No response

Suggested solution

No response

Carbon version

latest

Design tokens version

No response

Relevant browsers

Chrome

Relevant OSs

Windows

Additional context

No response

Confidentiality

• [X] I confirm there is no confidential or commercially sensitive information included.

[nineteen88]

Hi @Chris3y - can I ask what the use case of this is, as I'd like to get @harpalsingh's opinion on it as it seems a bit weird from a UX perspective? From a Carbon Developer perspective it will create some issues if we're messing around with contextual z-index's like that and we could introduce further "whack-a-mole" situations. If there's a valid use case, we will certainly look into what we can do, but it feels like a bit of an edge case beyond the scope of the date picker component on the surface.

[ConnollyM]

Hello, So the business requirement for this is: We record requested delivery date and a promised delivery date on a sales order, if the user enters a date into either field we launch a dialog that gives them the option them to change the date on all Sales Order Lines. The Order Lines could have separate dates. The 2 dates fields are in line and the tabbing order would allow the user to enter in a requested delivery date and then tab into the promised date field. I have added a screenshot of our new sales order screen for a visual reference.

We need away of controlling the datepicker popup or control the z index to appear behind the overlay of the dialog.

[harpalsingh]

Would like to bring @tempertemper into this conversation, as it seems opening a dialog from a date input blur? presents a variety of issues, in particular around accessbility and do we inform the user of this flow? I feel we should review the use case of this before we determine the z-index issue itself as that could have many knock on issues,

[Chris3y]

Would it be possible to give us manual control over the opening and closing of the datepicker popup? That way, we could manage this ourselves.

[nicktitchmarsh]

@harpalsingh , @ljemmo. How do you guys feel about exposing an open prop to control the daypicker being open or not and an openOnFocus prop that could be set to false for this scenario. Niche behaviour but in this use case something Carbon should probably provide as the alternative is that projects do their own date component which isn't useful for them.

[ConnollyM]

From a product point of view , the addition of an open prop would be ideal for our scenario.

[ljemmo]

@nicktitchmarsh fine from my perspective.

[edleeks87]

As this state is managed internally I think adding the ability to control the open state will lead to a few issues, such as knowing when a blur of the input was caused by a user tabbing to the picker element to select a date. I think it will be better to surface a callback that will be called when the user blurs the input and the picker is closed. I've made a very rough example in this branch, the last commit has the callback I've mentioned above but I also added a commit before that adding the ability to control so if you interactively rebase to it. Both examples can be seen via running storybook and testing the default date story which has been updated to replicate the above stackblitz

[ljemmo]

This sounds more like a dev implementation issue from my end. Happy to go with @edleeks87's approach if thats industry norm here.

[edleeks87]

FE-6761

[tempertemper]

From an accessibility stand point, we would want the date picker to close when the dialog is opened; after leaving the dialog the date field should be refocused and the date picker opened again. But this would presumably force the user to open the Dialog again when the field is blurred?

As a side note this sounds like a less than ideal user experience to have their intended action (tabbing fields) be interrupted by an unexpected Dialog. Would it be possible to rethink how this interaction works? Perhaps an edit all rows button that launches the dialog instead?

[carbonci]

:tada: This issue has been resolved in version 142.13.2 :tada:

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot :package::rocket: