Please provide a PR.

Sorry @lordfolken but it doesn't seems simple enough to me (or at least some guidance will be required)

I noticed the close_button at

but I'm pretty sure some changes are also required on the "caller" side

I've created a commit for this that...works, but feels like a bit of a hack. It is also perhaps incomplete because I think the Alternates dialog could benefit from having the same behavior. HeroicLemon@82fc215

I am also wondering if this could potentially break a user's existing .xci file somehow. I don't think changing the behavior like this would cause problems, but I also do not have a good feel for what sorts of things a user is able to do with the custom inputs yet. Should something like InputEvents::eventWaypointDetailsPersistent be created in order to ensure that past behavior is maintained?

Please create a PR and set it to draft. Then it runs through our qa and testing stage, and we can have a discussion on the topic.

It is debatable whether this is a good idea. I don't think it is. If you just want to look up a waypoint and inspect it, you then need an extra click to return to the map.
But in any case, the linked patch is bad because it creates a new list dialog every time. This loses all state.

I have created the draft PR as requested #749

It is debatable whether this is a good idea. I don't think it is. If you just want to look up a waypoint and inspect it, you then need an extra click to return to the map.

A good point. On my last flight, I had actually been attempting to look at the details for multiple waypoints and found the current implementation a little annoying before I even saw this issue on GitHub, but if I did just want to look at the details for a single waypoint it could also be annoying to have to click twice to get back to my main view. Adding a separate InputEvent could allow a user to decide how their dialog behaved, but I would suspect many users don't make use of that feature?