Add tooltips for bookmark and edit path buttons

[jelly]

Explain the bookmark and edit path button with a tooltip.

Related: #581

[martinpitt]

Tech review ok, waiting for @garrett for design review. Although we don't really have many knobs here, it's just standard PF Tooltip usage.

[garrett]

This doesn't work right. Try going from bookmarks to edit. You can't.

You never want tooltips or popovers covering up related parts of the UI that follow (to the right especially or under, generally. But as there's no room above and no related items below, having the tooltips at the bottom would be the best solution here.)

In other words: Move the tooltips under the icons, not to the side. Thanks!

[garrett]

Screencast of what I mean:

Kooha-2024-07-15-13-44-30.webm

[jelly]

Fixed:

[garrett]

Much better, thanks!

However, now we have another problem: When you have a tooltip and activate the button, you can't easily see and click on the Home entry at the top.

Would there be a way to not show the tooltip when the dropdown of the widget is visible? At that point you already know what the button does and it only gets in the way.

Here's a silly little screencast to show the problem:

Kooha-2024-07-15-16-48-14.webm

[garrett]

(reviewed in the previous comment; GitHub is lousy about this, as not all reviews involve code reviews)

[garrett]

I pushed a working fix @ 9306b35; it's not ideal, but it adds a class to the element when the menu is open. I tried isVisible, but that would override the hover and focus, which isn't what we want... we don't want to replace the behavior, but add on to it.

I also tried pf-v5-u-hidden from https://www.patternfly.org/utility-classes/accessibility#hidden — but we'd need to import that. And even then, display: none (which this uses) causes the tooltip to be in an odd place when it came back from toggling the menu back off.

Therefore, I hide it visibly and pass through all mouse (so it's not intractable) and clicks pass through the invisible version of it.

Anyway, feel free to augment it or even revert it, as long as we have some kind of fix that isn't too gross of a hack.

(I had some other ideas, such as changing the appendTo and applying CSS off of the state, either from within the element or a sibling element... but this method felt less intrusive.)

[garrett]

I'll approve now, but the last commit was mine, so I'm biased. I'd like someone else to verify this works for them and review again. Thanks!

(I think whatever approach we use to fix this will be some degree of "hacky". I think this is probably the least hackiest.)

[martinpitt]

Cheers!