DOM Event Interview Questions: Capture, Bubbling, and Shadow DOM Paths

A click handler on a page sees a custom-element host as event.target, although the user pressed a button inside its shadow tree. Another event reaches the host without bubbling through ordinary ancestors. Neither observation is explained by “events always bubble from the clicked element.”

For DOM event interview questions, separate four decisions: the dispatch path, the listener's phase, the target visible to that listener, and whether the event cancels a default action. Shadow DOM makes these distinctions observable rather than optional vocabulary.

The traces below are original browser exercises, not candidate reports or predictions of an employer's prompt. Platform facts come from the DOM Standard and linked API documentation, checked September 30, 2026.

How do capture, target, and bubbling differ?

Event dispatch invokes eligible listeners along an event path. Capture listeners run toward the target; target listeners handle the target invocation; bubbling listeners run outward when the event's contract permits it. Listener registration and event flags together determine which callbacks execute.

Standard fact: DOM dispatch distinguishes capturing, at-target, and bubbling phases. Both capture and noncapture listeners can run at the target, with capture listeners first. bubbles: false does not eliminate capture or target handling. DOM event dispatch algorithm.

Take an ordinary connected tree with outer > inner > button. Register one capture and one noncapture listener on each node, using a new event type called probe. Dispatch a bubbling event at the button. The original expected sequence is outer capture, inner capture, button capture, button noncapture, inner bubble, outer bubble.

Both button callbacks report AT_TARGET, not one capture phase and one bubble phase. Change only bubbles to false: the two ancestor capture callbacks still run, followed by both button callbacks. The ancestor noncapture callbacks disappear.

This trace is more useful than a memorized arrow diagram because it identifies the precise listener registrations. If someone logs only event names without node, phase, and capture mode, two distinct execution paths can look identical.

What are target, currentTarget, and composedPath?

target describes the event target as exposed to the current observer. currentTarget identifies the object whose listener is executing. composedPath() returns the observable dispatch path. These values answer different questions: origin as exposed, current handler location, and path membership.

API fact: currentTarget is meaningful during listener invocation, and composedPath() accounts for shadow-tree visibility. In particular, an outside observer does not receive closed-root internals in that path. DOM event interface, composedPath documentation.

In an ordinary delegated handler on outer, a button dispatch can have target === button while currentTarget === outer. That is how one container callback can handle events from many descendants.

For asynchronous work, snapshot what the callback needs before yielding. After the listener returns, do not rely on event.currentTarget still identifying the container. Save const container = event.currentTarget or a semantic identifier immediately, then use that saved value.

Also distinguish the event path from a fresh DOM traversal. A listener can move or remove a node during dispatch. An ancestor scheduled on the already-built path can still receive the event even though a later parentNode traversal shows another tree. Inspect the captured path and timing before diagnosing that as duplicate dispatch.

Which stop method changes which outcome?

stopPropagation() stops further propagation along the path. It does not generally suppress other listeners in the same invocation. stopImmediatePropagation() also prevents remaining listeners there. Neither method by itself cancels a default action.

API fact: immediate stopping prevents later listeners on the same element as well as further propagation. stopImmediatePropagation documentation.

Use an original trace with two noncapture listeners on inner, registered in order. The first calls stopPropagation(). The second still logs, but the noncapture listener on outer does not. With immediate stopping, neither the second inner listener nor the outer bubble listener logs.

The target and earlier capture callbacks have already executed in this fixture. Stopping propagation cannot undo them. Put the stop on an outer capture listener instead and you change which later nodes are reached; placement is part of the answer.

Avoid the vague statement “it stops the click.” Name the effect: an analytics ancestor misses the event, a sibling listener is suppressed, or a navigation default remains available. Different requirements need different controls.

Does preventDefault stop dispatch?

No. It requests cancellation of a cancelable default action; other listeners can still execute. This matters when a form handler should prevent submission while allowing other code to observe the event.

API facts: preventDefault() has no effect on a noncancelable event, and a passive listener cannot cancel through it. dispatchEvent() invokes listeners synchronously and returns false when a cancelable event was cancelled. preventDefault, dispatchEvent.

An original custom-event test can separate these contracts without navigating away. Create new Event('probe', {bubbles: true, cancelable: true}); one listener calls preventDefault(), and an ancestor records defaultPrevented. The ancestor still runs and sees true; dispatch returns false.

Repeat with cancelable: false: the ancestor still runs, sees false, and dispatch returns true. No browser navigation or form behavior was tested by that custom event. A real interaction test is necessary when the requirement concerns an actual default action or trusted user input.

A listener exception is also different from default cancellation. Do not assume a surrounding try/catch on dispatchEvent() catches every exception thrown inside a listener; the API reports listener exceptions as uncaught rather than propagating them to that caller. Dispatch exception behavior.

How do bubbles and composed interact with Shadow DOM?

bubbles controls ordinary outward bubbling. composed controls crossing a shadow boundary. They are independent flags. Synthetic events default to false unless their constructors receive another value; inspect the actual event instead of transferring assumptions from a native click.

Standard fact: a composed event can reach a shadow host with AT_TARGET treatment. Therefore, a composed nonbubbling event can still reach outside capture listeners and host handling, while skipping ordinary ancestor bubbling. DOM dispatch rules.

In an original fixture, append a host inside outer, attach a shadow root, and place a button inside it. Register capture and noncapture callbacks on the root, host, and outer container. Dispatch probe from the internal button under these policies:

Event flags	Outside behavior in this fixture
composed: false, either bubbles value	The event remains inside the shadow boundary.
composed: true, bubbles: false	Outer capture runs; host callbacks receive at-target treatment; outer noncapture does not run.
composed: true, bubbles: true	Outer capture and noncapture run, with host at-target handling between them.

A particularly revealing observation is the host's noncapture listener running for the composed nonbubbling event. Calling it “a bubbling listener, so it cannot run” confuses registration mode with the invocation's at-target treatment.

This example does not say all native events share the same flags. When moving from a custom probe to focus, keyboard, pointer, or form events, read that event's contract and test it in the relevant browser.

What changes between open and closed shadow roots?

An outside listener can see the host as its retargeted target for an event originating inside the shadow tree. An open root can expose inner path entries through composedPath(). A closed root omits those private entries from an outside observer's path. Observable path example.

Closed mode does not prevent a composed event from reaching outside listeners. It changes which internals those listeners can observe. Likewise, open mode does not make a noncomposed event cross the boundary.

For a component API, my recommendation is to publish a semantic event such as selection-change, with a stable payload identifying the selected value. Consumers should not need to search for a private button class or infer meaning from the first path entry.

If the public event intentionally crosses the boundary and participates in container delegation, configure both flags explicitly. Keep private interaction events private when they do not represent a public component action. That is an API design choice, not a universal instruction to make every custom event composed.

Closed shadow roots are also not an authorization boundary. Do not put secrets into event detail or assume private markup makes sensitive data safe to expose. The observable event contract deserves its own review.

How do you make delegation and cleanup reliable?

For a plain-tree dropdown, an event target may be an icon inside the actionable button. A handler can locate the nearest matching ancestor, but it should verify that the result belongs to its intended container. Otherwise nested components or unrelated nodes can trigger the wrong action.

For a shadow component, choose between an exposed path-based interaction contract and the component's public semantic event. A selector traversal using closest() does not magically pierce a shadow root. Outside code receiving a retargeted host should not pretend it has found the internal clicked button.

Listener API facts: removal must use the same callback identity and matching capture value. once removes a listener after its eligible invocation; an AbortSignal can remove associated listeners when aborted. addEventListener options and lifecycle.

An original teardown test mounts a component twice, performs one interaction, and asserts one update. Then unmounts and dispatches again: no update. Save callback references or use a per-mount abort controller. Recreating an equivalent arrow function during removal is a different function identity.

Listener registration during dispatch needs care too. Rather than assuming every newly registered callback runs immediately, keep installation and event handling separate, and test any deliberate dynamic-registration behavior against the standard's invocation rules.

What should a browser trace actually record?

Record node identity, eventPhase, target, currentTarget, bubbles, composed, cancelable, and defaultPrevented. Snapshot composedPath() while handling the event. These observations let you distinguish a missing listener from a hidden path entry or an already-stopped propagation path.

The original fixture passed 30 assertions in Chrome154. Its saved results check ordinary-tree ordering, both stop methods, default cancellation, all four flag combinations, and outside path visibility for open and closed roots. Its synthetic events verify dispatch behavior; they do not certify keyboard accessibility, touch gestures, browser default actions, or cross-browser compatibility.

A useful rehearsal changes one dimension at a time. First switch bubbling, then composition, then root mode, then the position of a stop call. Predict the trace before running it. If the output differs, locate the first unexpected invocation rather than rewriting all handlers.

Five frontend exercises to rehearse

Some involve frameworks; keep this exercise focused on the underlying DOM contract before introducing framework event behavior.

Question	Event-specific follow-up
Design a Reusable Dropdown Menu Component	Explain outside-click detection and a semantic selection event.
Implement Hook and Modify UI Interactions	Preserve callback identity and prove teardown removes listeners.
Implement paginated, sortable dynamic table component	Delegate nested button events without misclassifying icons.
Implement a Publish-Subscribe Event Bus in JavaScript or TypeScript	Contrast custom bus delivery with a DOM propagation path.
Build a Reliable Streaming Chat UI	Separate event handling, async work, and component lifetime.

Return to the dropdown exercise. Draw its tree, mark the shadow boundary if present, and write one expected trace for selection and another for outside interaction. Clear paths and observable cleanup make the answer reviewable.

Sources and Further Reading

• WHATWG DOM Standard: dispatching events
• MDN: addEventListener options and cleanup
• MDN: composedPath and open/closed roots
• MDN: stopImmediatePropagation
• MDN: preventDefault
• MDN: dispatchEvent