What I have described as my desired behavior may be too complicated. @Pginer-WMF, you should decide how the opening and closing of menu should work, once hover support is added.

In T188743#4017978, @Petar.petkovic wrote:

What I have described as my desired behavior may be too complicated. @Pginer-WMF, you should decide how the opening and closing of menu should work, once hover support is added.

I was thinking on supporting this as we do for the "..." button on Flow. It opens on hover (which is enough on desktop), but provides support to be opened by clicking too and is expected to be closed by clicking if it was opened that way.

What you proposed seems a valid solution, just a couple of comments:

• When the menu is opened on hover and the user clicks on the button we want to avoid the menu to close as you indicated. But we don't need to fix the menu to become open until clicking again/outside to be closed. Leaving the menu open, and closing based on moving the cursor out is also a valid option. I'm ok with either approach, whatever is simpler to achieve technically.
• I don't think we need to delay the menu to be closed a few seconds after the cursor moves out of the menu. We may want to make sure that there are no gaps between the active areas that could make the menu to close accidentally, and we may want to expand them to avoid accidentally moving outside when moving from the button to the menu items. I'm not sure if the time approach was proposed as an alternative to achieve this, but I'd consider it only if the active areas or expanding them turns out to be problematic.