This seems to be the same issue that was reported #1251 But it got back with new versions.
Create several popups with a click trigger.
Click first trigger --> first popup opens, then click second trigger --> the second opens, but the first stays open.
The first popup should be closed when the second trigger clicked.
The first popup stays open.
0.82.0
馃憢 Thanks for opening your first issue here! If you're reporting a 馃悶 bug, please make sure you've completed all the fields in the issue template so we can best help.
We get a lot of issues on this repo, so please be patient and we will get back to you as soon as we can.
Hello guys,
First, thanks for your amazing work !
I think I found the bug, can I submit a PR ?
Yep, feel free to pickup any issue marked as help wanted 馃憤
This line seems to be responsible. When adding the event to the second trigger, it is removing the targetHandler of the first one, hence removing its document listener (for a "click" in our case).
Is there a particular reason this is done this way ?
Yep, it's hard to describe, but you can try to remove/move this line and check how it affects sidebar examples. The ideal solution, fix current bug and keep current behaviour of Sidebar examples. Not easy 馃惐
Indeed, it is harder to comprehend than expected.
From my investigation, removing and adding that handler on the second portal mount prevents the first one to receive the click event (the one that causes the second portal to mount).
A "na茂ve" analogy would be that removing & adding a click listener on a document click won't trigger the listener just added.
A lazy solution would be to avoid sharing an EventStack instance between every Portal components so the listeners management will not be mixed.
Sidebar, which actually suffers the same bug, could take advantage of that solution too.
The thing is that components like Sidebar expect the system to work as described above. So if we try to do it smarter by actually managing each handler in the eventPool without removing & adding the eventListener to the DOM, the Sidebar (an other) component will add the event that will be triggered directly (hence closing directly the newly visible sidebar).
I think the eventStack -> eventTarget -> eventPool -> eventSet system is flawed for these cases. It would work if each component added/removed themselves their own callbacks to the document.
What do you guys think ?
Hi there, good job investigating! I discovered this bug with Dropdown component - https://codesandbox.io/s/m5x3k8y10p which brought me here, will help if needed :)
Hello guys, is there a plan / direction to solve this bug ? I could work on it if we agree on a solution.
@lucmerceron I would be grateful if anybody could solve it
@lucmerceron I'm currently busy with my paid work.
EventStack was moved to the separate repo. The solution is reorder and change event subscribing, more details are there https://github.com/Semantic-Org/Semantic-UI-React/pull/3124#issuecomment-420039264. The help is much appricated.
It seems that we will have issues with Sidebar, but it's better to resolve the current problem.
I think I've been experiencing this bug in my app. The JSX looks something like:
<Dropdown key="outlineKey" text="Outline" item closeOnBlur direction="left">
<Dropdown.Menu>
<Dropdown.Item

What I find interesting is that the first dropdown is closed OK. It's the second dropdown that doesn't close. But only if the second dropdown opening action caused another dropdown to close.
Perhaps this little tidbit will help with debugging. I can also test any solutions against my codebase to verify a fix. Good luck, this one doesn't seem easy!
This issue is very critical for our application.
Can somebody help?
Thanks
@ivanjiang5628 make popup controlled
It's the high priority issue to me, I will work on it at the current week. The next release should contain the proper fix.
@ivanjiang5628 make popup controlled
@dmitriyshmatov Thanks for replying
I can resolve the problem with adding a "force update" & "force update onChange function" states to the parent component then pass them to children(Popups) as props .however it will slow down the application render speed significantly due to the multiple rendering.
@layershifter Thank you
Manually checked the new release, the issue is fixed in [email protected].
Most helpful comment
Manually checked the new release, the issue is fixed in
[email protected].