A dropdown closes itself using a click listener on document. Inside an unrelated modal, a click handler calls event.stopPropagation(), and now the dropdown never closes. Explain the mechanism, and how you would fix it without breaking the modal.

## What actually broke The dismiss pattern — a listener on `document` that closes an open overlay whenever a click lands outside it — works because clicks bubble all the way up. `stopPropagation()` called anywhere below `document` ends the walk at that node. Every listener further out simply does not run. The damage is invisible at the call site. The modal author has no idea what else listens on `document`: outside-click dismissal, analytics, focus management, a keyboard-shortcut router, a drag controller. `stopPropagation()` silently removes the event from all of them. This is why it is the most over-used call in DOM code and a favourite senior interview scenario — it tests whether you reason about the whole path or only your own component. ## Fix one: listen during capture Capture descends from `window` to the target's parent before the target fires at all. A `document` listener registered for capture therefore runs **before** any handler inside the page can stop anything: ```javascript document.addEventListener('click', (e) => { if (!dropdown.contains(e.target)) closeDropdown(); }, true); ``` This is the standard hardening for page-level concerns, and it is why library dismiss logic and analytics collectors so often listen in capture. The tradeoff is that it also runs for clicks a component legitimately wanted to keep private — capture is deliberately un-suppressible from below, so you have opted out of the cooperation mechanism entirely and must decide for yourself what to ignore. A second consequence: because your handler runs *before* the component's, the DOM you inspect is the pre-handler DOM. If your dismiss test depends on state the component is about to change, capture changes what you observe. ## Fix two: delete the stopPropagation Ask what the modal's handler meant. Almost always it meant "this click belongs to me, nobody else should treat it as an outside click". That is a *claim*, not a *deletion*, and the platform already has a way to publish a claim: cancel the event and let others read `event.defaultPrevented`. ```javascript modal.addEventListener('click', (e) => { e.preventDefault(); /* handle */ }); document.addEventListener('click', (e) => { if (e.defaultPrevented) return; if (!dropdown.contains(e.target)) closeDropdown(); }); ``` Now analytics still sees the click, focus management still sees it, and only the code that opted into checking the flag stands down. In a shared codebase this is the better default, and "we banned `stopPropagation()` in components" is a defensible convention to bring up. ## Fix three: test containment instead of relying on non-arrival Often the dismiss handler does not need to be shielded at all — it needs a better predicate. `if (dropdown.contains(event.target)) return;` decides from the event's own data rather than from whether the event survived the trip. Combined with capture, this is the most resilient shape. ## The sibling call: stopImmediatePropagation `stopPropagation()` prevents the event visiting further **nodes**, but the remaining listeners already registered on the *current* node still run. `stopImmediatePropagation()` additionally suppresses those. It is the right call in exactly one situation: you need to guarantee that no other handler on the same element — including one registered by code you do not control — reacts. Using it as a stronger-sounding synonym for `stopPropagation()` is a red flag, because it makes your own component's second handler mysteriously stop firing. ```javascript el.addEventListener('click', (e) => e.stopPropagation()); el.addEventListener('click', () => console.log('still runs')); // swap in stopImmediatePropagation and the second listener never fires ``` ## Diagnosing it in the wild The symptom is always "my handler does not fire, and I can prove the event happened". A quick capture-phase probe on `document` (`document.addEventListener('click', console.log, true)`) tells you whether the event ever started. If capture sees it and bubble does not, something in between stopped it, and Chrome DevTools' Event Listeners pane on the ancestors will find who. ## What the interviewer is checking That you name the path and the exact node where it ended; that you know capture as the structural escape hatch; and that you propose removing the `stopPropagation()` rather than only routing around it. Answers that stop at "add capture: true" solve the ticket but miss the design point.