Explain DOM event capturing and bubbling with addEventListener

WHAT THIS TESTS: This tests whether you understand the full lifecycle of a DOM event and can manipulate it deliberately. Senior engineers need to know propagation order to debug delegated events, avoid double handling, and build robust component layers without leaking listeners everywhere.

A GOOD ANSWER COVERS: First, describe the three conceptual zones: the capture phase moves from the window or document root down through ancestors to the event target, the target phase fires on the element itself, and the bubbling phase moves back up from the target to the root. Second, explain that addEventListener registers listeners in the bubbling phase by default, but you can switch to capture by passing true as the third argument or by passing an options object like { capture: true }. Third, mention that most common events bubble, but some like focus, blur, and scroll do not bubble by default, which is why delegation patterns sometimes fail. Fourth, note that event.stopPropagation halts further propagation in the current phase, while event.preventDefault stops the browser's default action, and these are orthogonal concerns.

COMMON WRONG ANSWERS: A red flag is claiming that events only bubble and capture is legacy or unused. Another is saying the third argument is exclusively a boolean and ignoring the options object form. Confusing stopPropagation with preventDefault is a classic error. Also, asserting that all events bubble will immediately signal shallow experience.

LIKELY FOLLOW-UPS: An interviewer might ask when you would intentionally use capture phase, such as intercepting events before they reach nested components. They might ask how event delegation works and why it relies on bubbling. They could also probe what happens if a listener calls stopPropagation during capture, or ask about passive listeners and how they interact with preventDefault.

ONE CONCRETE EXAMPLE: Imagine a modal with a close button inside an overlay. If you attach a click listener to the overlay in bubble phase to close the modal, clicking the close button might trigger both handlers and close the modal twice or reopen it. Using capture phase on the overlay, or checking event.target versus event.currentTarget, lets you control exactly when and how the overlay responds relative to its children.

Source: developer.mozilla.org