I'm using Material-UI Popper component and using it with its keepMounted prop set.
The issue I'm having is that when the Popper's component open prop is false the popper goes of out of the window boundaries but remain visible.
Q: What approach should I use to ensure that the popper is not visibled/displayed when the Popper component's open is false?
I've looked into it (see below for more details) but without success.
I've setup a small repro and example code here:
https://codesandbox.io/embed/389w75jpom
Scroll to the bottom when the tooltip/popper "isn't shown" and notice that it's still visible. Clicking the button toggles the value of the Popper component's open property.
I'm hoping for the popper to be hidden when open is false while still using keepMounted. I would prefer if it wouldn't be shown at all (e.g display: none) not just go out of sight.
From Material-UI docs, I’ve seen that popper.js modifiers can be passed using the modifiers prop and look at modifiers~hide specifically.
In the doc it's mentioned that the hide modifier:
[...] will set a x-out-of-boundaries attribute which can be used to hide with a CSS selector the popper when its reference is out of boundaries.
As per the doc this modifier should be enabled by default but it seems that the x-out-of-boundaries attribute doesn't seem to be applied to the popper container div at all.
So I haven't been able to rely on a CSS selector in this case.
I've also found this GH issue that I believe led to the implementation of the hide modifier.
I've tried to pass down [1] to the modifier a hidePopper function similar to the one suggested in the same GH issue here to detect when the popper goes in and out of the boundaries and set its style accordingly. Here's a fork of the previous repro with the code updated to reflect this:
https://codesandbox.io/embed/jvr6oy95j3
But the boundaries attribute is not present on the data object passed to the function (see the console logs) when testing here:
https://jvr6oy95j3.codesandbox.io/
Sorry if I'm missing something and would really appreciate any guidance on this. Thanks
[1] via the hide.fn modifier attribute.
Related
With MUI 5.0.2, When all the IconButton-s in a ButtonGroup go on the same side, the hover background shape will change.
And other elements also affects this (a Button with/without href property on one side)
It is said in another question by #Ryan Cogswell, that the styling for the border is using :not(:last-of-type) in the selector. This implies that MUI is using class on and , which seemes very slopy to me.
Is this is a bug?
I hosted a minimal environment with GitHub Pages. The question is shown on the first and forth chapter.
(all pictures shown here are showing with on hover)
Button with href
Button without href
Button without href on hover
Also I made a related issue on official repo, and in my Learning note
I was having an accessibility issue when using Material-UI with React. Specifically when placing a Menu on a Drawer. Essentially the normal behaviour of a Menu is to highlight the top MenuItem. This behaviour is different if that menu is placed on a Material UI Drawer.
I have recreated the problem here using just the example Material-UI Menu and Drawer:
https://codesandbox.io/s/material-ui-menu-and-drawer-accessibility-issues-xjj3h?file=/src/App.js
The following images show the difference between the two menus when opened. I am using the chromevox extension while testing:
A normal menu when using chromevox to show accessability:
A menu when it is placed on a material UI drawer:
Would anyone be able to point out if this is an error in my code or if perhaps there are any workarounds? Was going to raise this as a new github issue but felt it was worth asking the question here first. :)
By default, the drawer enforces (so long as it is open) that focus stays within itself. So when the menu opens and grabs focus, the drawer notices that it lost focus and it grabs it back.
There are two options for fixing this:
You can turn off this drawer behavior by specifying the disableEnforceFocus prop (example here).
You can specify the disablePortal prop on the menu (example here). This will cause the menu to be a descendant of the drawer in the DOM (by default the menu uses portals and is added as a child of the <body> element), so the drawer will not try to "take back" the focus, because when focus is in the menu it will still be within the drawer.
I would recommend option 2 since the drawer's focus enforcement is generally a good thing from an accessibility standpoint.
I'm using the following component:
https://material-ui.com/components/popper/
In the DOM, it has the role of tooltip. I expect that it would automatically get the tooltip zIndex from the theme here:
https://github.com/mui-org/material-ui/blob/master/packages/material-ui/src/styles/zIndex.js
But it gets no z-index. What gives?
Seems like you're using a component that is too low-level. The zIndex.tooltip you've mentioned is being used in the Tooltip component. So you have two options:
Switch your code to be using Tooltip directly and don't worry about applying zIndexes around
Keep your Popper implementation apply the zIndex manually. Or use withStyles, just like the Tooltip component does.
For a greater flexibility and control over how stuff gets done, I would prefer the second approach, to be fair.
New to React and MUI, and having a UX issue where when we have a popover (dropdown menu, or autoselect dropdown) we can still scroll the main body of the site. I see that its fixed in the new beta V1 for MUI, but using the current stable release, Ive been asked to see if we can hack it up to stop the scrolling - but I cant seem to target/catch anything when we have a popover appear.
Examples: Current MUI - http://www.material-ui.com/#/components/auto-complete
V1 Beta MUI - https://material-ui-next.com/demos/autocomplete/
So, if you were to input something in those examples and trigger the downdown/popover, youll see that in the current MUI, you can still scroll the
I was hoping someone may have had this issue and had a solution they'd like to share?
Thanks guys!
I had a similar problem and solve it using 'disablePortal' Autocomplete property:
You can take a look at 'disablePortal' definition in here:
https://material-ui.com/api/autocomplete/#props
disablePortal: Disable the portal behavior. The children stay within it's parent DOM hierarchy.
I also had to add some styles to get pop up get positioned relative to input component.
Here is some sort of example:
const useStyles = makeStyles({
popperDisablePortal: {
position: 'relative',
}
})
const classes = useStyles()
<Autocomplete
classes={classes}
disablePortal={true}
{...props}
/>
So you may have to:
set up disablePortal property
define associated popperDisablePortal style with 'relative' position
EDIT: actually this error should not happen as part of default MUI Autocomplete set up. In my case, the error was some conflicting CSS property that was generating this scroller bug. Not sure in your case, but to me it happens to be some overflow: auto property defined on page HTML tag (sometimes you can find it on body tag). Replace with overflow: 'visible' and scrolling error should be gone without even changing one line of autocomplete component definition.
The documentation for the react-bootstrap overlay trigger says that the overlay prop can be an element or text. However, whenever I pass it something other than a "Tooltip" component it doesn't work. In fact, if you modify their code example on the website linked below to be just a div instead of a Tooltip or a string, it doesn't work on their site either. Does it have to be passed a Tooltip?
https://react-bootstrap.github.io/components.html#tooltips-overlay-trigger
Easiest thing to pass is a Tooltip or a Popover.
You could also pass it something else, but then you have to wrap it in an Overlay instead of an OverlayTrigger. See the react-bootstrap docs on Custom Overlays for more specific examples.