[ClickAwayListener] failed to rasing onClickAway if you have an element that is removed from DOM when clicked
See original GitHub issueIf you have a React component/html element that’s going to be hidden when clicked, the ClickAwayListener
will fail to trigger the onClickAway
due to the following condition
if (
doc.documentElement &&
doc.documentElement.contains(event.target) && // <-- event.target no longer in the DOM
!nodeRef.current.contains(event.target)
) {
onClickAway(event);
}
- The issue is present in the latest release.
- I have searched the issues of this repository and believe that this is not a duplicate.
Current Behaviour 😯
When clicking on an element that gets hidden on click, the ClickAwayListener
ignores the click and doesn’t trigger onClickAway
event.
const handleClick = () => { setShowButton(false); };
const handleClickAway = () => {
//This is not being called when clicking on the button below
setClickAwayStatus('Registered onClickAway event from ClickAwayListener');
};
{showButton && (<Button onClick={handleClick}>
Click to hide
</Button>)}
<p>{clickAwayStatus}</p>
<ClickAwayListener onClickAway={handleClickAway}>
<div>
{/* ... */}
</div>
</ClickAwayListener>
Expected Behaviour 🤔
The onClickAway
should be triggered and not care about whether the event source is removed from the DOM
Steps to Reproduce 🕹
Steps:
- Open the codesandbox link: https://codesandbox.io/s/festive-dust-fftxt
- Click on anywhere except the button labelled “Click to hide”
- Notice the the paragraph text changes to “Registered onClickAway event from ClickAwayListener”
- After 2 seconds the paragraph text should reset to “Waiting for event”
- Now click on the button labelled “Click to hide”
- Notice the paragraph text is still “Waiting for event” and will never reset to the previous text since the
ClickAwayListener
onClickAway
event wasn’t triggered.
Context 🔦
I’m using the ClickAwayListener
with Popper
to display a popup menu, and wants it to close when ever I click outside the opened menu. The behaviour works as long as you don’t have components or html elements that are removed from DOM on click. I want the menu to close even if i click on other elements that are removed from DOM.
Your Environment 🌎
Tech | Version |
---|---|
Material-UI | v4.9.5 |
React | v16.12.0 |
Browser | Google Chrome: v80.0.3987.132 (64-bit) |
Issue Analytics
- State:
- Created 4 years ago
- Reactions:1
- Comments:5 (5 by maintainers)
Top Results From Across the Web
[ClickAwayListener] failed to rasing onClickAway if you have ...
The behaviour works as long as you don't have components or html elements that are removed from DOM on click. I want the...
Read more >ClickAwayListener doesn't fire when clicking on a link/button ...
ClickAwayListener component works by attaching the event listener to the document , when a mouse event fires, it fires onClickAway only when ...
Read more >ClickAwayListener API - MUI Base
Name Type Default
children * element
onClickAway * func
disableReactTree bool false
Read more >front-end/node_modules/@material-ui/styles/CHANGELOG.md
A way to get location (latitude and longitude), elevation, speed and other relevant data from individual satellites from the Starlink constellation.
Read more >Create Your Own Click Away Listener using React - LinkedIn
When the click away component renders, React will set a reference to the DOM node so we can use it later on to...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
@seare-kidane Thanks for the update. As far as I understand it, the check of
doc.documentElement
serves no purpose, we can save it. Do you think that you will have time to work on a pull request? 😃@oliviertassinari Sorry for my late response, it’s been a tough time 😞. Anyways, delaying the removal of the element should also work and regarding the proposed change in #20197 (comment), I don’t think removing
doc.documentElement
is necessary, since the it was not the source of the issue.