Don't close 2 dialogs from 1 escape keydown (more-info)

[karwosts]

Proposed change

There are a couple places in more-info dialog that open another dialog on top, such as "change the device area" dialog, or the detailed item dialog for schedule.

Currently one escape press will close both dialogs, which I think it not expected. I'd expect first press to close the top dialog, second press to close the more-info dialog.

Similar implementation as this exists already in hui-dialog-edit-card.

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New feature (thank you!)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Example configuration

Additional information

• This PR fixes or closes issue: fixes #
• This PR is related to issue or discussion:
• Link to documentation pull request:

Checklist

• The code change is tested and works locally.
• There is no commented out code in this PR.
• Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated for www.home-assistant.io

[MindFreeze]

You're right that it's not intended. I just couldn't find a good way to handle this centrally

[MindFreeze]

Maybe we should have a parent Dialog class or mixin to handle this logic as it would be very verbose to add it to every dialog that might lead to another

[wendevlin]

FYI ha-md-dialog doesn't have this issue. Maybe we should wait with this, till we decided how to continue with our ui framework?

[MindFreeze]

Another approach could be to always disable escapeKeyAction, then catch the escape key and pass it to the dialog manager to figure it out.
Or the dialog manager can tell the existing dialogs (call method like it does for closeDialog) that they are not on top when opening a new one.

[karwosts]

I just couldn't find a good way to handle this centrally

It doesn't happen that often I think, (as I think the pattern is already discouraged), so it might not be bad to just bespoke fix it in the one or two places it creeps up.

I think ths schedule case is also a bit nasty as now people can take a fair bit of time to setup a detailed schedule, and one errant keystroke can cause that all to be lost without warning. So it might be nice to fix this even if it's slightly redundant with some major redesign planned for the far future.

[wendevlin]

@karwosts you are right, we can merge this and if we gonna migrate the framework we need to rework at it either way.

Thank you!

[wendevlin]

@karwosts can you please solve the merge conflicts?

[karwosts]

@karwosts can you please solve the merge conflicts?

Resolved