[chip] Delete icon calls `event.stopPropagation()`

[caillou]

Steps to reproduce

Steps:

1. Open this link to live example: https://stackblitz.com/edit/ob1sd6fc?file=src%2FDemo.tsx
2. Click on Open Popper button.
3. Click on the x icon in the <Chip />.

Current behavior

The <Popper /> is not closed when clicking on the x icon if the <Chip />.

Expected behavior

Given the <ClickAwayListener /> in the <Popper />, the <Popper /> should be closed when clicking anywhere else, including when clicking on the x icon if the <Chip />.

Context

I use a <ClickAwayListener /> to close a <Popper />. Given that the <Chip /> event handler calls stopPropagation(), the click event never reaches the <ClickAwayListener />.

It seems like stopping propagation could be done by the onDelete handler that's passed into the Chip, rather than by default.

Your environment

npx @mui/envinfo

  System:
    OS: Linux 5.0 undefined
  Binaries:
    Node: 20.19.1 - /usr/local/bin/node
    npm: 10.8.2 - /usr/local/bin/npm
    pnpm: 8.15.6 - /usr/local/bin/pnpm
  Browsers:
    Chrome: Not Found
    Firefox: Not Found
  npmPackages:
    @emotion/react: latest => 11.14.0 
    @emotion/styled: latest => 11.14.1 
    @mui/core-downloads-tracker:  7.3.5 
    @mui/material: latest => 7.3.5 
    @mui/private-theming:  7.3.5 
    @mui/styled-engine:  7.3.5 
    @mui/system:  7.3.5 
    @mui/types:  7.4.8 
    @mui/utils:  7.3.5 
    @types/react: latest => 19.2.2 
    react: latest => 19.2.0 
    react-dom: latest => 19.2.0 
    typescript: latest => 5.9.3 

Search keywords: stopPropagation propagation Chip ClickAwayListener

[mj12albert]

It seems like stopping propagation could be done by the onDelete handler that's passed into the Chip

@caillou Did you mean that users supplying a onDelete prop must call stopPropagation themselves? It would be a breaking change which we can't make in the mean time, but otherwise I'm not opposed to it 🤔

The issue is that stopPropagation is needed to prevent "delete clicks" from triggering the onClick on the Chip (which is a separate issue itself...)

[caillou]

@mj12albert Thanks for your quick response.

Out of curiosity, could you elaborate why we need to prevent the onClick from being triggered when we click on the x icon?

Would maybe adding an allowPropagation for now be a way forward? allowPropagation could be immediately deprecated, and removed once we introduce the breaking change?

Or is there a way to somehow get around this stopPropagation without rebuilding my own Chip?

[NikolaPantel]

This isn’t a Chip bug. The delete icon intentionally stops propagation so a delete-click doesn’t also trigger the Chip’s onClick or parent handlers (e.g. reopening a Select). We’ve had regressions in the past when it didn’t stop (see #18658, #27614). Removing it would be a breaking change.

[mj12albert]

I would say this is indeed a Chip bug, but the fact that "delete" stops propagation is not a bug

Possibly we could stopPropagation in onDelete only if both onDelete and onClick are present

[caillou]

I think we could get away without having to prevent the default.

If there is an onDelete present, then onClick could do something like this:

const deleteButtonContainsEventTarget = (event) => {
  return event.target instanceof HTMLElement &&
    deleteButtonRef.current?.contains(e.target)
}

const onClick = (event) => {

  if (!props.onClick) {
    return;
  }

  if (deleteButtonContainsEventTarget(event)) {
    return;
  }

  props.onClick(event);

}

The same could be done for the mouseDown that triggers the animation.

I implemented an example here:

https://stackblitz.com/edit/ob1sd6fc-hxq74tvz?file=src%2FDemo.tsx

In the example, clicking the blue delete button does closes closes the <Popper /> but does not trigger the onClick on the <Chip />.

[mj12albert]

OK I think this is worth a try 👍

[Shashank-Venkatesh]

@mj12albert Yes, I went through it and understood the issue. I’ve applied the necessary fix.

[Shashank-Venkatesh]

@mj12albert I believe I understood what was required and have applied the changes in the file accordingly.