[UX] Update menu popover positioning to be consistent with Help menu

[joshuarrrr]

Is your feature request related to a problem?
As part of investigating and implementing a new global header, we discovered some minor discrepancies between the popover implementation of the help menu and the user menu:

(this appears to use anchorPosition="downCenter" implicitly; however, it appears as if it's positioned as leftUp)

vs
anchorPosition="downRight"

What solution would you like?
@kgcreative would like all menu popovers to display the same, with a preference for them appearing under the menu item. In theory, just explicitly specifying anchorPosition="downRight" should be sufficient to match the help menu styling. However, further investigation may be necessary to understand why it's not currently displaying as expected.

[peternied]

Thanks for the great bug report, this looks like something that was missed during the latest UI updates for version 2.0.0.

[joshuarrrr]

I've looked a bit more at this, and there's something pretty subtle going on. It only happens on some pages, and only to the right-most element. I'll need to take a closer look at the EUI source code.

[RyanL1997]

I've looked a bit more at this, and there's something pretty subtle going on. It only happens on some pages, and only to the right-most element. I'll need to take a closer look at the EUI source code.

Hi @joshuarrrr , I was taking a look of this issue yesterday. It did happen only to the right-most tag, even though I've tried to specify the anchorPosition=downRight in account-nav-button for the user profile popover. I also noticed that we've changed the header layout that we have moved the help element right to user profile element, and the issue is happening on the help popover for now.

Is there anything we can find in the EUI that related to this popover issue for now?

[peternied]

@opensearch-project/transfer-request Can we get this issue moved to the OUI project?

[ashwin-pc]

I'd seen a similar behavior in another tooltip lib. There this was a soft requirement based on the position of the tooltip, so that the tooltip was always visible. So if the tooltip ever wen outside the viewport, it switched to another mode to make sure it was visible. Might just be the same thing under the hood.

[kgcreative]

Sounds like we may need to add some padding to the base component so the help icon doesn't run up against the edge of the viewport. That will likely cause the tool-tip to show up in the correct place.

[ashwin-pc]

Just throwing this out there, what's the need to make it consistent in the first place? Looking at a lot of UIs, including the popovers in MacOs and Windows, this behavior is pretty standard. It doesn't even look inconsistent if we think of them as popovers/tooltips. I think we are confusing popovers with drop-down menus, which is a different UI element all together. If the ask here is to change them to be drop down menus, I'm a lil more inclined, but even then I wouldn't prioritize this over some of the more urgent UI fixes we need.

Like they say, if it ain't broke

[kgcreative]

I'm ok putting a pin on this temporarily. I do think the icon feels a bit too close to the edge though. With that said, eventually clicking help will open a side drawer instead of triggering a popover, so this will be moot.

[joshuarrrr]

I think we are confusing popovers with drop-down menus, which is a different UI element all together. If the ask here is to change them to be drop down menus

Yeah, honestly, I think that hits the nail on the head. 💯

[joshuarrrr]

I think we are confusing popovers with drop-down menus, which is a different UI element all together.

I think this is still what bothers me most - we commonly use Context Menu to approximate a dropdown menu, but it's implemented as a popover. This makes it difficult to reason about how to use those components effectively. For example: opensearch-project/OpenSearch-Dashboards#2904