Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Portalled tooltips appear behind modals/overlays that have z-index
See original GitHub issueBug report
Using a portalled tooltip in an overlay or modal that has a z-index means the tooltip gets positioned behind the modal.
Current Behavior
Portalled tooltips are placed at end of <body> with <radix-portal> element and a <div> with positioning. These cannot be styled specifically for tooltip instances and therefore can’t have z-index set on them. So they can’t appear above any item that created them that has a z-index.
To attempt to fix I set the tooltip portalled to false, but this also illustrates the problem from this issue where a not portalled tooltip inside a positioned element such as a modal will not be positioned correctly:
Expected behavior
Portalled tooltips appear above the elements that create them and/or can have a z-index set on them and are positioned correctly.
Reproducible example
Suggested solution
Give the positioning div a [radix] attribute to allow styling with a z-index.
Your environment
| Software | Name(s) | Version |
|---|---|---|
| Radix Package(s) | Tooltip | 0.01 |
| React | n/a | 16.12 |
| Browser | Chrome, FF, Safari, Edge | Latest |
| Assistive tech | n/a | |
| Node | n/a | 10.17 |
| npm/yarn | Yarn | 1.22.10 |
| Operating System | Mac + Windows | Latest |
Issue Analytics
- State:
- Created 3 years ago
- Comments:9
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
Hey @mattaningram, just a heads up in case you are still depending on the
radix-portalselector as a hack (and haven’t moved to the new selector), we are introducing some change to ourPortalwhich should actually negate all these hacks in the first place. See #410 for more context.That would be perfect!
In the short term I’m using the
radix-portal > div { z-index: … }approach, and in long term going to remove the z-index from my non-Radix modal/overlay components to address issue overall (since you are right that ideally they shouldn’t need them).Adding those additional
data-radix-*attributes will allow people to fix this issue if they can’t fix their modals.Thank you! Looking forward to getting more Radix primitives into our codebase soon.