fix(overlays): no hiding of nested overlays having hideOnEsc configured

[tlouisse]

closes #2198

[changeset-bot]

🦋 Changeset detected

Latest commit: c798ce5

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@lion/ui	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

If the child overlay has hidesOnOutsideEsc set to true, does not mean the parent overlay should close.

[ryubro]

My general idea about JS event is that an event is just thrown with details no more than its type and the target then more details should be investigated from the target by the event handler.

Do you think it's better if we let this handler investigate the target to decide if it has been already handled?

[tlouisse]

I can make it cleaner by storing these data in a Weakmap instead of on the event. The thing here is that it passes two nested overlays and the parent one should know about the child one, so just checking the target is not a solution

[tlouisse]

See https://jsfiddle.net/rmsc6u73/ to see what we're trying to achieve

[ryubro]

Thank you for the example! Great to see how the dialog element simplify things.

How do you think about making the OverlayManger know about parent-child relationship of overlays and handle what should happen when the ESC key was pressed?

I think nested popups often comes with different way to display which can benefit from the central manager:

• We might want to have control on the background of the popups (ex: making the half-opaque background to stack to make the background darker or just keep the background opacity)
• We might want to put the child popup so that it looks neatly stacked above the parent, especially on mobiles
• In the previous company, the designer decided to put the child popup contents in the parent popup like the iOS navigation menu (https://developer.apple.com/documentation/uikit/uinavigationcontroller)

Anyway, I'm not insisting, just a suggestion.

[tlouisse]

I really like the scenarios you describe. It would be great to create them in a demo (as a lion extension example) and see what's needed to build them :)

With all the recent platform developments (especially wrt popover) we have a great opportunity to make things more lightweight (I think we still need the manager and controller, see https://hidde.blog/popover-accessibility, https://adrianroselli.com/2023/05/brief-note-on-popovers-with-dialogs.html, etc.).
Let's refine the future of the system together and have a brainstorm session about how we can make it better with modern technology.

Currently, I have a draft doc that explains the origins (and potential future) of the overlay system. I'm also thinking about ways to make the manager opt-in. Since we're using dialog inside today we can leverage the document order (whereas before we moved contents to the body and needed the OverlayManager to keep track of their ordering). Having this dom order intact, we have a lot of opportunities css-wise and by querying the dom.