blueprint: Popover Elements (Tooltip, Popover, Overlay) do not open with Portals
Environment
- Package version(s): 3.10
- Browser and OS versions: Chrome, Firefox and Safari (latest). MacOS 10.14.1 (latest)
Steps to reproduce
- Use
<Popover /> anywhere with usePortal={true} (default behaviour)
- Click on the popover target
Actual behavior
- No popover content appears when clicked
-
bp3-popover-open class still appears on the target
- No portal div appears at the bottom of the page
- Setting the
usePortal prop to true gets rid of the bug.
Expected behaviour
- Popover opens within a portal div and is visible.
Possible solution
- I supect this is not a CSS issue as the problem seems to be that the portal div is not being added at all to the bottom of the page.
Other Information
- This bug occurred during an upgrade from Blueprint Version 3.6 to 3.10. Consequently, it seems likely that the error is due to one of the following, Portal-related pull requests:
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 3
- Comments: 21 (4 by maintainers)
Commits related to this issue
Generally it’s best practice to inject application scripts at the bottom of body anyway, so as to not block HTML rendering.
Ah… well, that’s interesting. So actually including
<%= javascript_pack_tag "application" %>in the HTMLheadcausesdocument.bodyto be initiallynullwhen all the scripts run. I think this is causing Blueprint some headache… likely there’s some initialization code for the Portal that doesn’t like this.Moving
<%= javascript_pack_tag "application" %>to the bottom of thebodyseems to solve the issue.@mulholio that default gets set further down the component stack: https://github.com/palantir/blueprint/blob/3dcbb0113f7f58637dec57a85c445011d51bafb6/packages/core/src/components/portal/portal.tsx#L59. so I don’t think your suggested change would fix this.
but I will admit it’s confusing for Overlay’s docs to list
@default document.bodyfor itsportalContainerprop when it doesn’t actually do any default handling itself (only Portal does that).Still not resolved, but we have found that by setting
portalContainer={document.body}(the default) portals render correctly.