Open WC ui5-datepicker calendar inside UI5 dialog, click "ESC" wrongly close whole dialog

[mydavidzhang]

Bug Description

Open WC ui5-datepicker calendar inside UI5 dialog, click "ESC" wrongly close whole dialog. This issue happens to all WC component that has popup inside SAP UI5 dialog sap.m.Dialog.

Expected Behavior

Click "ESC" should only close the popup and keep dialog open.

Steps to Reproduce

1. Go to https://snippix.only.sap/#735560 or some page has UI5 dialog contains WC component which has popup.
2. Open popup of WC component
3. Click "ESC" Actual behavior: whole dialog is close. Expected behavior: only popup closed and dialog is open.

Isolated Example

https://snippix.only.sap/#735560

Context

• UI5 Web Components version: 1.6.0
• SAP UI5 version 1.102
• Browser: Chrome
• Affected component: component has popup like ui5-datepicker

Priority

• [ ] Low

• [x] Medium

• [ ] High

• [ ] Very High

• Organization: Successfactors

[MapTo0]

Hello,

This is not the way to mix web components and UI5. It happens due to the different Popup registry of both frameworks (all listen for last open popup and close it on ESC).

Regards, Martin

[mydavidzhang]

Hi Team, could you guide the solution to fix this issue? And any WC library API could be used to solution this issue? Thanks

[codefactor]

@MapTo0 ,

Please provide the proper way to mix web components and UI5 - since we have use cases today in which UI5 web components are being used as widgets in which a Renderer will render a Web Component inside of the body of a UI5 content.

Note - we already knew the root cause to the problem before we opened this issue, but what we are looking for is guidance on how to avoid such layering problems that are coming up today.

If you're basically saying that we cannot use a DatePicker from UI5 Web Component library when the parent is a UI5 component, then that is a highly disappointing.

[vladitasev]

Hello colleagues,

Sorry for the confusion - Martin and I discussed the issue and we clarified that this is an integration scenario, and not trying to use a single web component in an otherwise pure OpenUI5 app (in which case one would have used sap.m.DatePicker instead).

Now to the issue at hand - we have an ongoing discussion with the core team regarding the deeper integration of the OpenUI5 / Web Components popup registries. Such an integration would allow both components to "know about each other" in terms of escape handling, open popups chain, etc...

In the meantime, the best I could come up with was: https://snippix.only.sap/#169976

sap.m.Dialog has an escapeHandler property (full API here: https://sapui5.hana.ondemand.com/#/api/sap.m.Dialog%23controlProperties) which expects the user to either resolve or reject a promise. The solution is to implement this escapeHandler, and, if the datepicker is open, manually close it and reject (telling the dialog not to close itself), otherwise resolve - telling the dialog to behave normally.

I know this is a workaround and in a productive scenario you might even not know what is inside the dialog, let alone query it and determine/manipulate its state. It's much easier to fix it for an isolated example as this one.

So please let me know if you can make this workaround work for your specific use case. In the meanwhile I'll check our progress on the topic with the OpenUI5 core team and get back to you in this ticket.

Regards, Vladi

[pskelin]

Update: while the escape handler above seems to solve the issue, the actual problem is that when the date picker is opened, the focus doesn't go in the popover and the date cannot be selected by keyboard. This happens because the sap.m.Dialog does not recognise the date picker popover as part of the dialog and steals back the focus incorrectly.

As @vladitasev mentioned, we are working with the OpenUI5 team for a better web components integration.

[ilhan007]

Hello @mydavidzhang due to the vacation period the owners of the Popup from the OpenUI5 Core team are not available, that's why we don't have update on the issue. We expect to have progress the second or third week of Sep, when everybody is back again.

[ilhan007]

Hello @mydavidzhang we got in touch with the OpenUI5 Core team, we will make an update on how we'll move the issue forward later this week. FYI @don-obrien.

[ilhan007]

Hello @mydavidzhang the sample is pretty clear to demonstrate the issue - thank you for that. We would like to also ask you what is the expected content of such dialog (I assume much more than a single date picker). Could you give us more real-case scenario dialog with its expected content - we want to be sure we won't miss anything.

[codefactor]

@ilhan007 ,

To give some background, we have a general calendar widget built with our general-purpose widget-loader library. The library is framework agnostic, so it can be used in a React/UI5 or any other framework (at least that's the goal). We want all the thousands of places in SuccessFactors that displays either a date picker or calendar to utilize this widget - and so in this way we can control things about how dates are displayed in SuccessFactors in a single place (such as if buddhist/islamic/gregorian calendar is used, or if there is a secondary calendar displayed, configurable by the user).

The widget is independently packaged and deployed separately from everything else - and the widget exposes a simple API which consumer can call to render a Calendar or DatePicker or handle events when the user does something on the widget. We would like there to be an effective knowledge barrier between the consuming application and the underlying widget, so that we can effectively update the implementation of the Calendar without ever having to touch the outer application code.

If the calendar widget needs to know about the Dialog parent to register something on the Dialog instance, that is certainly possible to do - but we would most likely localize that knowledge into the Widget layer -- so the Widget could select for known elements that are containing the Calendar and then discover the sap.m.Dialog instance and then attach things to that instance, so that way the Application that creates the Dialog does not need to do anything special.

But as you say, it would be nice to have a better solution - on which multiple popup frameworks can "know about eachother" so that the intermediate layers (like the application layer or the widget layer) do not need a hack that crosses knowledge barriers to fix accessibility issues like this.

[ilhan007]

Hello @codefactor thank you for the comprehensive reply, long term we are looking for out of the box solution by having better integration between the ui5wc popup and sap.ui.core.Popup. However, we are also looking into all possibilities, that can be provided quicker as the integration could take time.

For example such solution could be the following: To have a special attribute (like data-sap-ui-integration-popup-content) that can be set to the ui5-datepicker tag, or any other ui5 web component that opens a popup. The idea is to transfer that attribute to the ui5-static-area-item that wraps the popup. The sap.m.Dialog already works with this attribute and the presence of this attribute will let the sap.m.Dialog recognise the popup as an external content and will allow the focus to go into the popup (the ESC behaviour will also work as expected once the focus correctly handled).

Do you think you can set data-sap-ui-integration-popup-content to the ui5-datepicker tag?

https://user-images.githubusercontent.com/15702139/194010250-25bf9ae7-0716-4c60-9a8e-9c44dac15f8e.mov

[codefactor]

While we could add such an attribute I'm not sure it is necessary.

If the attribute works when adding it to the popup static area item then why not add it all the time for any Popover?

What purpose does it have to require the date picker owner to opt-in to get this functionality? Wouldn't the widget always add this attribute?

[ilhan007]

Hi @codefactor I just wanted to check the worst case, we will see if this attribute can be set always without any side effects, f.e. for date pickers outside dialogs. If everything looks good, we can set the attribute always.

[ilhan007]

Hello @codefactor, we didn't find issues with always setting the data-sap-ui-integration-popup-content attribute to the static-area-item this what finally the change does. With this the issue with the ESC behaviour, described in the issue will be fixed. In addition, we will create a long-term BLI for deeper integration between UI5WC Popups and SAPUI5 Popup as the only way to cover all cases when mixing popups from the frameworks. I will link the BLI once ready.

I will close the issue as the specific problem with the ESC behaviour has been resolved with the following change.

BR, ilhan