'Help' tooltip is obstructed behind the navigation toolbar border

I fired up an MR thinking this would be easy. I spent a good half hour just finding where that border is defined that is obstructing the tooltip. It's here, for future me or others that come to this issue 😅

https://git.drupalcode.org/project/drupal/blob/11.x/core/modules/navigat...

I am with @dalin at DrupalCon Portland 2024, and I am going to look at fixing this issue within the next hour.

I'm mentoring @aronm on how to contribute to their first d.o issue.

Problem:

The tooltip itself has a z-index of 801. The .admin-toolbar::after element which is part of admin-toolbar, has a z-index of 501. The #menu-footer has a z-index of -1, which is overriding the 801 z-index of the tooltip.

Changing the z-index of #menu-footer to a higher value caused the element to overlap .admin-toolbar and make the border disappear.

Tried applying a border-inline-end to the #menu-footer, which caused a flicker when the menu expanded.

The arrangement of all the associated elements needs be refactored to fix this correctly. However, a simpler fix is to change the hardcoded offset position of the tooltip in tooltip.js. Shifted the offset from 6px to 18 px.

Thanks @javi-er for assistance with this issue.

Thank you for you work here!

In my point of view we still need to fix z-index and we cannot move tooltip.

I see 2 ways:
1. Manage border on menu level.
2. Backport popover api approach from https://www.drupal.org/project/drupal/issues/3197758 ✨ Create a new component: Toggletip RTBC it will be on top layer
https://developer.chrome.com/blog/introducing-popover-api

In any case i don't think it is novice issue anymore.

Looks good. Issue fixed. No regressions. Thank you!

ckrina → changed the visibility of the branch 11.x to hidden.

ckrina → credited javi-er → .

Committed 981989f and pushed to 10.3.x. Thanks!

We considered the implemented approach but the problem with this is that when the menu slides to the right it covers the borders for a short amount of time causing some flickering, that's why the original approach used an :after pseudoelement imo.
It's a tiny issue and not very noticeable, so I'll leave to the maintainer to decide if further action is needed, see attached video.

Automatically closed - issue fixed for 2 weeks with no activity.