We actually rely on the useEffect semantics i.e. the click handler should not be attached synchronously. Otherwise, we might handle the event that mounted the component. Unfortunately, react 17 has a bug where effects are flushed synchronously in portals so we have to find a userland workaround.

Benefits over #23313: Since we have many listeners we would need to repeat it whenever we add the event listeners. Touches might behave the same as clicks so we're fixing the same problem for touch events as well. There's an argument to be made to get rid of mountedRef/activatedRef entirely since that's no different from just removing the handler but the "mounted"-pattern helps here since we don't have to repeat this quirky logic everywhere. If the bug is fixed we should be able to get rid of the ref entirely. That IE11 comments is curious. React 17 removes the listener asynchronously anyway so I wonder if there's a realistic chance that we trigger a click-away between unmount and removal of the listener.

I was not able to write a test for it since the synchronous flush only happens on a user-click and not programmatic (element.click) or dispatched (element.dispatchevent) click.

facebook/react#20074 tracks the React bug.

Closes #23215
Closes #23313

Test plan

• Added test fails in React 17 before fix: https://app.circleci.com/pipelines/github/mui-org/material-ui/25651/workflows/979393e5-e3fc-4b60-904a-c8c80ffcc262/jobs/191785
• Added test passes in React 17 after fix: https://app.circleci.com/pipelines/github/mui-org/material-ui/25654/workflows/046392bb-f599-4f9a-a8fb-46090bbb1106/jobs/191798
• Verify fix in codesandbox using this PR: https://codesandbox.io/s/material-ui-issue-forked-ptpxo?file=/src/Demo.js
• existing test pass in React 16 and 17