[looking for input] fix: Dialog/dropdown: Handle issue where clicking dropdown causes it to close in a dialog

[margaree]

Jira ticket

TODO:

• [ ] Tests
• [ ] Add simplified example

Problem: When a dialog consists of asynchronous content where the first focusable item is a dropdown, clicking the dropdown can often cause it to close.

Issues at play:

1. When something has focus in the dropdown and then the dropdown is clicked elsewhere, the blur event is triggered, triggering the __onAutoCloseFocus method. There seems to be a bit of a race condition here between the blur and the clicked item in the filter receiving focus. A timeout increase was added here to handle this piece.
2. When the dialog content eventually loads, focusableContentElemPresent needs to get set to true, else the dialog content is considered to be the active element here if something non-focusable is clicked on in the dropdown (the timeout fixes things if something focusable is clicked in the dropdown, but not if something non-focusable is clicked; that's what the remainder of the changes are for).

The changes I've made here fix things for several cases but not all, so curious for others' thoughts.

Why was this seemingly fixed if a different dropdown got opened? When the other dropdown menu was opened, hierarchical mixin was running __removeAncestorTabIndicies which was turning the tab-index=0 on the dialog content into data-d2l-hierarchical-view-tabindex. This seems weird. I didn't handle that here but it should probably have a separate ticket.

[github-actions[bot]]

Thanks for the PR! 🎉

We've deployed an automatic preview for this PR - you can see your changes here:

URL	https://live.d2l.dev/prs/BrightspaceUI/core/pr-5659/

[!NOTE] The build needs to finish before your changes are deployed. Changes to the PR will automatically update the instance.

[dbatiste]

When something has focus in the dropdown and then the dropdown is clicked elsewhere, the blur event is triggered, triggering the __onAutoCloseFocus method.

Given that this is happening in the blur handler, the relatedTarget should be the element that is receiving focus. There is a comment in __onAutoCloseFocus about lack of browser support for relatedTarget - I recall running into that browser support issue many years ago. I think all the browsers have supported relatedTarget for a long time now. Maybe we could use it to resolve this case... I'd be curious to know what relatedTarget in this case.

[Update] I suspect relatedTarget is that dialog element with tabindex="0". So maybe that doesn't help us.

[dbatiste]

Another idea... maybe we just shouldn't auto-close if the active element is any ancestor element of the dropdown. The dropdown would remain open, and then presumably close once it detects focus has moved to a non-ancestor element.

I'm always apprehensive about the idea of focusable elements inside other focusable elements. That setup seems to be biting us here.

[margaree]

Closing in favour of https://github.com/BrightspaceUI/core/pull/5674 which is simpler.