[ClickAwayListener] Calling onClickAway straightaway when used with Select

• 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 Behavior 😯

When a Select is used in conjunction with the ClickAwayListener, the onClickAway prop is called straightaway after the select is open.

Expected Behavior 🤔

It should not call onClickAway while the Select is opening. onClickAway should only be called when the user clicks OUTSIDE the select while it’s open.

Steps to Reproduce 🕹

Steps:

1. Open codesandbox
2. Click to open the select
3. Look at the console

Context 🔦

This issue was first raised in https://github.com/mui-org/material-ui-x/issues/1314.

Proposed solution 💡

@oliviertassinari did some investigation in https://github.com/mui-org/material-ui/issues/18586 and I confirmed that the same behavior is happening here too. The click event is being called with the target body which forbids any attempt of the ClickAwayListener to check if it was inside or outside its children. I propose the following change based on Olivier’s diff.

diff --git a/packages/material-ui/src/ClickAwayListener/ClickAwayListener.tsx b/packages/material-ui/src/ClickAwayListener/ClickAwayListener.tsx
index 6bb56f9c4e..984b7c22f0 100644
--- a/packages/material-ui/src/ClickAwayListener/ClickAwayListener.tsx
+++ b/packages/material-ui/src/ClickAwayListener/ClickAwayListener.tsx
@@ -123,6 +123,12 @@ function ClickAwayListener(props: ClickAwayListenerProps): JSX.Element {
       return;
     }

+    // The click event couldn't find its target, ignore
+    const eventTarget = event.target as Node | null
+    if (eventTarget?.nodeName === 'BODY' && event.type === 'click') {
+      return;
+    }
+
     let insideDOM;

     // If not enough, can use https://github.com/DieterHolvoet/event-propagation-path/blob/master/propagationPath.js

Your Environment 🌎

`npx @material-ui/envinfo`

  System:
    OS: Linux 5.4 Ubuntu 20.04.2 LTS (Focal Fossa)
  Binaries:
    Node: 15.12.0 - ~/.nvm/versions/node/v15.12.0/bin/node
    Yarn: 1.22.10 - ~/.nvm/versions/node/v15.12.0/bin/yarn
    npm: 7.6.3 - ~/.nvm/versions/node/v15.12.0/bin/npm
  Browsers:
    Edge: 89.0.774.63
  npmPackages:
    @emotion/react: ^11.0.0 => 11.1.5
    @emotion/styled: ^11.0.0 => 11.1.5
    @material-ui/codemod:  5.0.0-alpha.27
    @material-ui/core:  5.0.0-alpha.28
    @material-ui/data-grid:  4.0.0-alpha.21
    @material-ui/docs:  5.0.0-alpha.28
    @material-ui/envinfo:  1.1.6
    @material-ui/icons:  5.0.0-alpha.28
    @material-ui/lab:  5.0.0-alpha.28
    @material-ui/styled-engine:  5.0.0-alpha.25
    @material-ui/styled-engine-sc:  5.0.0-alpha.25
    @material-ui/styles:  5.0.0-alpha.28
    @material-ui/system:  5.0.0-alpha.28
    @material-ui/types:  5.1.7
    @material-ui/unstyled:  5.0.0-alpha.28
    @material-ui/utils:  5.0.0-alpha.28
    @types/react: ^17.0.3 => 17.0.3
    react: ^17.0.1 => 17.0.1
    react-dom: ^17.0.1 => 17.0.1
    styled-components:  5.2.1
    typescript: ^4.1.2 => 4.2.3

[eps1lon]

Still not a bug. This requires significantly more research than just glancing at the issue.

[oliviertassinari]

Sure, will let you know when the next issue comes up that wasn’t reported.

@eps1lon I don’t follow the link with the previous conversation. I also don’t recall we talk about this in the past. It seems that we are not talking about the same subject, but maybe we are, in any case, it seems to be a topic worth discussing 😃.

not a bug.

Let’s step a step back. There are two different notions, the product, and the tech.

• At the product level, we focus on determining what’s the right behaviors and experience for the users. What product should we build, which developer problems should we solve? What’s the most important and should be built first?
• At the technical level, we focus on the implementation of this behavior. How do we best build the product?

Then, there is an ongoing discussion between product and tech. The vision the product has might not be possible to implement, tech come up with possible options, with different product tradeoffs.

So whether a behavior is a bug or not, is ultimately a product decision. I’m still responsible for the product. If you disagree with my previous judgment call, labeling this GitHub issue a bug, then feel free to make a case for why. Until you convinced me, please keep the current label. I currently have no information that would start to suggest it’s not a bug. Labeling this a bug seems a straightforward judgment call.

@enheit Please open a new issue with minimal reproduction on the latest version. We are focusing on fixing the ClickAwayListener + Select issue here.