Modal root element makes certain types of hover interaction impossible

[jedwards1211]

Because Modal creates a screen-filling element, it seems like it's impossible to implement something like opening a submenu whenever a MenuItem is hovered. Either it's impossible to tell if the MenuItem is still being hovered (because it's blocked by the modal root), or the submenu can't get any pointer events, if I disable pointer events on its modal root, so that I can see if a MenuItem is being hovered.

My last issue about this seems to have been deleted because I complained about how difficult this has been. It's been very frustrating for me trying to fix this functionality in material-ui-popup-state to help one of the people using my library 😢 Can someone please show some sympathy for my frustration? We are humans, not robots. Only robots should be expected to show no emotion at all.

I had edited the issue to soften the language I wrote while angry. But I never called anyone names or used threatening language. I think you should allow me to say that I feel angry, and contend that something was a bad idea when I illustrate problems it's causing.

[mbrookes]

@jedwards1211 I deleted your issue because, as you say, you were in a state of anger, and the language reflected that. It seemed more appropriate to be discrete than comment publicly, so I contacted you on gitter to let you know I was deleting your issue, and copied the body if it there so that you could reuse the salient parts when you'd had a chance to relax and reflect.

You are right, we are all human, and being on the receiving end of vitriol is not pleasant for anyone, either the recipient, or those close by.

[jedwards1211]

Oh I see, do I show up on Gitter? I didn't realize because I never use Gitter, but I appreciate that you tried to contact me there.

I was being self-centered in asking for sympathy, when obviously the way I said things wasn't pleasant for you all to read. I'm sorry. I guess I should just focus on expressing that I've really suffered from trying to debug/solve an issue.

[jedwards1211]

Am I correct in my understanding that there's no way to prevent the modal root from blocking pointer events while still allowing the modal itself to receive pointer events? Maybe there's something I overlooked?

[joshwooding]

@jedwards1211 Do you have a minimal reproducible example? You can use this codesandbox template as a starting point.

[eps1lon]

Adding some research notes:

• menus includes "Dropdown menus" and "Exposed dropdown menus" (@eps1lon : so there are actually only dropdown menus)
• the first mock in the spec includes a submenu
• a menu with a submenu is called a "Cascading menu" in the spec
• cascading menus in google docs do not create a blocking backdrop; every other ui element is fully functional while menus are open
• material angular displays menus above the backdrop allowing cascading menus to open on hover while disabling the rest of the ui
• default placement is below the opening element not in front in the spec; our implementation defaults to in front
• we state that dropdown menus can be composed with our implementation but our implementation is actually already a dropdown menu
• cascading menus are currently marked as not supported

Work:

• make Menu demo page discoverable with dropdown search (currently linking to supported components page)
• backdrop should be controllable (disabled, enabled, between menus and rest of ui (matching angular)) Edit: This should disable the backdrop <Menu hideBackdrop />; see https://material-ui.com/api/modal/
• demo for cascading menu should be added

Resources:

• https://material.io/design/components/menus.html
• https://material.angular.io/components/menu/overview
• https://material-ui.com/getting-started/supported-components/#supported-components

[mbrookes]

Related issues: #8152 #11723

[jedwards1211]

I want to make clear that I'm not just talking about the modal backdrop; even with that turned off by hideBackdrop, the modal root element causes this problem. I'll try to come up with a sandbox

[jedwards1211]

material angular displays menus above the backdrop allowing cascading menus to open on hover while disabling the rest of the ui

But that means it would block the button or whatever that was originally hovered to open the top-level menu right?

My question is why even use an invisible modal root element or backdrop? Is it to determine if the user clicked outside?
Note that a click away listener can be implemented by adding a click capture listener to document.body using DOM API instead of React event listeners. Using a root element that fills the screen isn't necessary at all.

[jedwards1211]

An example of what I'm trying to do can be found here:
https://schier.co/blog/2014/10/23/creating-a-pure-css-dropdown-using-the-hover-selector.html

The menu opens when the button is hovered. Notice how it stays open while the menu or the button itself is hovered, and closes when neither is hovered.

It's not very difficult to do something like this by absolute positioning a Paper element as a child of the button, but it's utterly impossible to do this right now with Menu, which is the component people reach for when they want to create a dropdown menu.

[jedwards1211]

Okay I discovered that even though pointer-events: none on the modal root element makes all of its descendants invisible to the mouse, I can set pointer-events: auto on the descendants to make them visible to the mouse again. So there is a solution to this problem, not that it's elegant.

I still question the logic of rendering a Popover inside of an invisible screen-filling element that serves little purpose when the backdrop is hidden (which Popover does). But at least hover interaction isn't impossible.