fix: adjust tooltip z-index to fix hidden node labels in Explore search/pathfinding - BED-9077

[julian1j]

Hovering over a node kind icon in search or pathfinding rendered the label underneath the results list instead of over it. This is because TooltipContent used z-50, which sits below the app's overlay layers. the Explore search dropdown alone uses z-index 1300.

Proposed fix changes this to z-[1500], matching the other floating content in doodle-ui (Select content, DatePicker popover, Dialog content).

Description

Single file, one line modification, change z-50 to z-[1500]

Motivation and Context

Resolves BED-9077

Why is this change required? What problem does it solve?

How Has This Been Tested?

Tested locally in CE. Search for a node in Explore, hover over the node icon, you should see a tooltip/label for the node type.

Screenshots (optional):

Before:

After:

Types of changes

• Bug fix (non-breaking change which fixes an issue)

Checklist:

• [x ] I have met the contributing prerequisites
  • Assigned myself to this PR
  • Added the appropriate labels
  • Associated an issue: Issues and Pull Requests README #672
  • Read the Contributing guide: https://github.com/SpecterOps/BloodHound/wiki/Contributing
• I have ensured that related documentation is up-to-date
  • Open API docs
  • Code comments (GoDocs / JSDocs)
• I have followed proper test practices
  • Added/updated tests to cover my changes
  • All new and existing tests passed

Summary by CodeRabbit

• Bug Fixes
  • Improved tooltip visibility by ensuring tooltips appear above other interface elements when overlapping content.

[coderabbitai]

📝 Walkthrough

Walkthrough

The tooltip content z-index utility changes from z-50 to z-[1500]; no component logic, props, or rendering behavior changes.

Changes

Tooltip stacking order

Layer / File(s)	Summary
Raise tooltip stacking order packages/javascript/doodle-ui/src/components/Tooltip/Tooltip.tsx	TooltipContent now uses z-[1500] instead of z-50.

Estimated code review effort: 1 (Trivial) | ~2 minutes

Suggested reviewers: sirisjo

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title clearly describes the main change: increasing tooltip z-index to keep node labels visible in Explore.
Description check	✅ Passed	The description follows the template with Description, Motivation, Testing, Screenshots, Type of change, and checklist sections.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

_{Comment @coderabbitai help to get the list of available commands.}

[bfaulk96]

Makes sense to me. I actually ran into a related issue on the "Manage Clients" page last week.

[elikmiller]

It may be preferable to ensure the parent container has a separate stacking context instead of changing the z index of the tooltip at the component library level
https://developer.mozilla.org/en-US/docs/Web/CSS/Guides/Positioned_layout/Stacking_context

[bfaulk96]

It may be preferable to ensure the parent container has a separate stacking context instead of changing the z index of the tooltip at the component library level https://developer.mozilla.org/en-US/docs/Web/CSS/Guides/Positioned_layout/Stacking_context

I think Tooltips are rendered in a React portal, which takes them out of the component stack? I had a similar issue to the one shared here, where tooltips that were defined around components in a Menu were showing behind the menu because of that..

I could definitely be wrong on that assumption, but that's at least how MUI's tooltips work (I imagine Radix – our underlying tooltip provider – does something similar)

[elikmiller]

It may be preferable to ensure the parent container has a separate stacking context instead of changing the z index of the tooltip at the component library level https://developer.mozilla.org/en-US/docs/Web/CSS/Guides/Positioned_layout/Stacking_context

I think Tooltips are rendered in a React portal, which takes them out of the component stack? I had a similar issue to the one shared here, where tooltips that were defined around components in a Menu were showing behind the menu because of that..

I could definitely be wrong on that assumption, but that's at least how MUI's tooltips work (I imagine Radix – our underlying tooltip provider – does something similar)

That sounds like a good assumption. I suppose as long as our design system/component library is not prescriptive about z-indicies then this change is fine. The other solution that occurs to me would be to isolate the react root element into a separate stacking context wholesale via https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Properties/isolation

I bring it up because I'm not confident that this change to the component library won't trigger visual regressions in other areas of the app. But we can squash them if we find them.