Fix call node context menu being hidden behind source view bottom box#6045
Open
canova wants to merge 1 commit into
Open
Fix call node context menu being hidden behind source view bottom box#6045canova wants to merge 1 commit into
canova wants to merge 1 commit into
Conversation
The CallNodeContextMenu and MaybeMarkerContextMenu were rendered inside .Details, which sits inside .DetailsContainer. DetailsContainer sets `position: relative; z-index: 0`, which creates a stacking context that capped the context menu's z-index at 0 relative to its siblings. Since the BottomBox is a sibling of DetailsContainer declared later in the DOM, it always painted on top of the context menus, and it makes them unreadable when the source view was open. Moved both context menus from Details.tsx into ProfileViewer.tsx, and placed after BottomBox, so they share a stacking context with both DetailsContainer and BottomBox. Their `--z-context-menu: 5` now paints above the BottomBox as intended. Context menus are wired to triggers by id rather than DOM proximity, so the move does not affect the behavior. Technically MaybeMarkerContextMenu can't be visible while we still have the source view visible, but I think it makes sense to keep them together.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #6045 +/- ##
==========================================
- Coverage 83.78% 83.77% -0.01%
==========================================
Files 329 329
Lines 34528 34546 +18
Branches 9659 9666 +7
==========================================
+ Hits 28930 28942 +12
- Misses 5169 5175 +6
Partials 429 429 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
fatadel
approved these changes
May 22, 2026
Contributor
fatadel
left a comment
There was a problem hiding this comment.
Hey @canova, thanks for the PR! I've tested it locally and it seems to work fine.
However, I've found an alternate fix worth considering: just drop position: relative; z-index: 0 from .DetailsContainer. Tested locally, fixes the same bug. It seems like nothing inside Details depends on that stacking context.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The CallNodeContextMenu and MaybeMarkerContextMenu were rendered inside .Details, which sits inside .DetailsContainer. DetailsContainer sets
position: relative; z-index: 0, which creates a stacking context that capped the context menu's z-index at 0 relative to its siblings. Since the BottomBox is a sibling of DetailsContainer declared later in the DOM, it always painted on top of the context menus, and it makes them unreadable when the source view was open.Moved both context menus from Details.tsx into ProfileViewer.tsx, and placed after BottomBox, so they share a stacking context with both DetailsContainer and BottomBox. Their
--z-context-menu: 5now paints above the BottomBox as intended. Context menus are wired to triggers by id rather than DOM proximity, so the move does not affect the behavior.Technically MaybeMarkerContextMenu can't be visible while we still have the source view visible, but I think it makes sense to keep them together.
Before:

After:

Example profile:
Before / after