JavaScript Event Propagation Interview Questions

The three phases of every DOM event

Every DOM event travels through three distinct phases in a fixed order. Understanding this order is the foundation of every event propagation interview question.

document
  └── html
        └── body
              └── div#container
                    └── button   ← you click here

Phase 1 — Capture: document → html → body → div → button
Phase 2 — Target: The event fires on button itself
Phase 3 — Bubble: button → div → body → html → document

The third argument to addEventListener controls which phase a listener runs in. Passing true registers a capture-phase listener. Omitting it or passing false registers a bubble-phase listener — which is the default almost every developer uses.

const button = document.querySelector('button')
const div    = document.querySelector('div')

div.addEventListener('click', () => console.log('div — capture'), true)
div.addEventListener('click', () => console.log('div — bubble'), false)
button.addEventListener('click', () => console.log('button — target'))

// Click the button → logs:
// "div — capture"
// "button — target"
// "div — bubble"

Bubbling — the default behaviour

When an event fires on an element, it then fires on that element's parent, then the parent's parent, all the way up to the document. This is bubbling — the event rises like a bubble through water.

<div id="outer">
  <div id="inner">
    <button id="btn">Click me</button>
  </div>
</div>

document.getElementById('btn').addEventListener('click', () =>
  console.log('button')
)
document.getElementById('inner').addEventListener('click', () =>
  console.log('inner div')
)
document.getElementById('outer').addEventListener('click', () =>
  console.log('outer div')
)

// Click the button → logs:
// "button"
// "inner div"
// "outer div"

The outer div handler fires even though the user clicked the button — because the click event bubbles through every ancestor. This is not a bug — it is the intended design.

Not every event bubbles. focus, blur, load, scroll, mouseenter, and mouseleave do not bubble by design. This is a common interview trap. Use focusin and focusout — which do bubble — when you need to delegate focus events.

stopPropagation vs stopImmediatePropagation

event.stopPropagation() stops the event from travelling further up or down the DOM. The current element's handlers still finish, but no ancestor handlers fire.

document.getElementById('inner').addEventListener('click', (e) => {
  e.stopPropagation()
  console.log('inner — stops here')
})
document.getElementById('outer').addEventListener('click', () =>
  console.log('outer — never runs')
)

// Click inner → logs: "inner — stops here"
// outer handler never fires

event.stopImmediatePropagation() goes one step further — it stops propagation AND prevents any other listeners on the same element from running.

const btn = document.getElementById('btn')

btn.addEventListener('click', (e) => {
  e.stopImmediatePropagation()
  console.log('first handler — stops everything')
})
btn.addEventListener('click', () =>
  console.log('second handler — never runs')
)

// Click → logs: "first handler — stops everything"

The difference: stopPropagation stops vertical travel through the DOM tree. stopImmediatePropagation also stops horizontal travel across multiple listeners on the same element.

preventDefault — the unrelated method that everyone confuses

event.preventDefault() and event.stopPropagation() are completely independent. This is the most commonly confused pair in DOM interviews.

preventDefault blocks the browser's built-in action for that event — navigation for links, form submission, checkbox toggling. The event still bubbles normally. stopPropagation stops the event travelling through the DOM. The browser's default action still happens.

// Link still navigates — bubbling stopped, default NOT prevented
link.addEventListener('click', (e) => {
  e.stopPropagation()
  // page still navigates to href
})

// Bubbling continues to parent listeners — navigation prevented
link.addEventListener('click', (e) => {
  e.preventDefault()
  // ancestor handlers still fire
})

// Neither navigates NOR bubbles
link.addEventListener('click', (e) => {
  e.preventDefault()
  e.stopPropagation()
})

event.target vs event.currentTarget

This pair appears in almost every senior frontend interview and trips up the majority of candidates.

event.target — the element the user actually interacted with. The origin of the event. It does not change as the event bubbles.

event.currentTarget — the element whose event listener is currently running. It changes at each step of propagation.

document.getElementById('outer').addEventListener('click', (e) => {
  console.log(e.target)         // #btn — where the click originated
  console.log(e.currentTarget)  // #outer — where this listener lives
})

Inside an arrow function used as an event listener, this refers to the outer scope — not the element. Use event.currentTarget instead of this when you need the element the listener is attached to.

// Regular function — 'this' equals the element the listener is on
btn.addEventListener('click', function(e) {
  console.log(this === e.currentTarget)  // true
})

// Arrow function — 'this' is NOT the element
btn.addEventListener('click', (e) => {
  console.log(this)             // undefined (strict mode) or outer scope
  console.log(e.currentTarget)  // btn — use this instead
})

Event delegation — the most important pattern

Because events bubble, you can attach a single listener to a parent and handle events for all its children — including children added to the DOM after the listener was attached. This is event delegation.

Without delegation — a listener per item, breaks on dynamic content:

// Does not work for items added after this runs
document.querySelectorAll('.item').forEach(item => {
  item.addEventListener('click', handleClick)
})

With delegation — one listener, works for all current and future children:

document.getElementById('list').addEventListener('click', (e) => {
  if (e.target.matches('.item')) {
    handleClick(e.target)
  }
})

This works because click events on any .item bubble up to #list, where the single listener catches them.

The closest() fix — handles nested elements inside the delegated target:

// Problem: user clicks the <span> inside <li class="item">
// e.target is the <span>, not the <li>
// e.target.matches('.item') returns false — event is missed

// Solution: closest() walks up from e.target until it finds a match
document.getElementById('list').addEventListener('click', (e) => {
  const item = e.target.closest('.item')
  if (!item) return   // click outside any .item — ignore
  handleClick(item)
})

closest() starts at e.target and walks up the DOM tree, returning the first ancestor that matches the selector — including the element itself. This handles any level of nesting inside the delegated element and is the correct delegation pattern in production code.

Custom events and the bubbles trap

You can create and dispatch your own events that participate in the propagation system. The most common mistake is forgetting that CustomEvent defaults to bubbles: false.

// Dispatches but does NOT bubble — parent listeners never fire
const broken = new CustomEvent('cart:updated', {
  detail: { itemId: 42 }
})
button.dispatchEvent(broken)

// Correct — explicitly enable bubbling for delegation to work
const event = new CustomEvent('cart:updated', {
  bubbles:    true,
  cancelable: true,
  detail: { itemId: 42, quantity: 3 }
})
button.dispatchEvent(event)

// Now this listener on document fires correctly
document.addEventListener('cart:updated', (e) => {
  console.log(e.detail.itemId)  // 42
})

removeEventListener — why arrow functions cause memory leaks

removeEventListener requires the exact same function reference used in addEventListener. Arrow functions defined inline are new references on every call, so they can never be removed.

// Leaks — a new arrow function is created each time setup() runs
function setup() {
  element.addEventListener('click', (e) => handleClick(e))
}
// This removes nothing — different reference
function teardown() {
  element.removeEventListener('click', (e) => handleClick(e))
}

// Correct — store and reuse the same reference
function setup() {
  element.addEventListener('click', handleClick)
}
function teardown() {
  element.removeEventListener('click', handleClick)
}

The { once: true } option is the clean alternative when the handler should only fire once — it removes itself automatically after the first invocation.

button.addEventListener('click', handleClick, { once: true })
// Fires once, then removes itself — no teardown needed