How input reaches your event handlers

One input, several decisions

When a finger moves, a wheel turns, or a mouse clicks, the browser first receives coordinates and an event type. It must decide whether it can update the screen quickly, whether JavaScript must get a chance to cancel something, and which page element should receive the event.

This lesson builds on the rendering pipeline. Rendering prepared layers lets a compositor assemble frames quickly. Input asks whether that same compositor can keep moving a scroll, or whether it must wait for the renderer main thread.

The words in this lesson describe a browser design, not an extra JavaScript event loop. Your handler still runs on the main thread. The useful question is whether the browser must wait for that handler before starting a default action.

Input handled on the compositor thread

The compositor thread combines already-painted layers into frames. For a scroll it can often move those layers without asking the main thread to run JavaScript or recalculate layout. That separation is one reason a page can keep scrolling while other work is busy.

1window.addEventListener("wheel", () => console.log("wheel seen"), {2  passive: true,3});4console.log("listener added");

Line 1 registers a listener on window. Line 2 marks it passive, which is a promise that it will not cancel the wheel event. Line 4 runs immediately and prints listener added. Later wheel input prints wheel seen in the console.

The listener is still useful for observation, analytics, or updating a small visual indicator. Passive does not mean skipped. It means the browser may start the default scroll without waiting to learn whether this particular listener called preventDefault().

Non-fast scrollable regions

A non-fast scrollable region is an area where a potentially canceling input listener means the compositor may need main-thread confirmation before it starts scrolling. Chrome records this information while it builds and composites the page.

1const listeners = [2  { target: "cart", type: "wheel", passive: false },3  { target: "menu", type: "touchmove", passive: true },4  { target: "map", type: "pointermove", passive: false },5];6 7const regions = markScrollableRegions(listeners);8console.log(regions.map((region) => region.region).join(","));

Line 2 gives cart a non-passive wheel listener, so the model marks it non-fast. Line 3 gives menu a passive touch listener, so it is fast. Line 4 is a pointer listener: it can run JavaScript, but it is not one of this small model's scroll-blocking listener types.

The result prints non-fast,fast,fast. This is a teaching model, not Chrome's region map. It makes one useful rule visible: non-passive wheel, touchstart, and touchmove listeners are the usual listeners that can require a scroll-start decision.

A wheel, touch, or pointer listener that could call preventDefault() changes the decision. The browser cannot know your function will be quick, and it cannot know it will decide not to cancel until it runs. A busy main thread therefore becomes visible as scroll-start delay.

1const passive = false;Run2const mainThreadBusyMs = 40;3 4function startScroll(passive, mainThreadBusyMs) {5  return passive ? 0 : mainThreadBusyMs;6}7 8console.log(startScroll(passive, mainThreadBusyMs));

The replay uses a tiny deterministic model. It does not measure Chrome, but it makes the dependency plain: a non-passive listener has a wait equal to the modeled busy time; a passive listener has a zero scroll-start wait. Real browsers add more detail, including event type and CSS.

Passive listeners and cancelable events

A cancelable event has a default action that a listener may be able to stop. Read event.cancelable before writing cancellation logic. Calling preventDefault() on a non-cancelable event does not change its default action.

1const target = new EventTarget();2 3target.addEventListener("checkout", (event) => {4  console.log("cancelable", event.cancelable);5  event.preventDefault();6  console.log("defaultPrevented", event.defaultPrevented);7}, { passive: true });8 9target.dispatchEvent(new Event("checkout", { cancelable: true }));

Line 3 adds a passive listener. Line 4 first prints cancelable true. Line 5 asks to prevent the default action, but that request is ignored because the listener promised not to cancel. Line 6 therefore prints defaultPrevented false in browsers.

Node's EventTarget does not model passive cancellation the way browser DOM does, so the lesson test proves this snippet in Chrome. Do not use a passive listener when cancellation is genuinely part of the feature. Prefer CSS such as touch-action when it describes the gesture policy more directly.

1// State the option instead of depending on a browser default.2document.addEventListener("wheel", recordScroll, { passive: true });3document.addEventListener("touchstart", startPan, { passive: false });4 5console.log("wheel observes; touchstart may cancel");

Line 2 explicitly says the wheel listener only observes. Line 3 explicitly says this touch listener may cancel because the feature needs that choice. Line 5 prints wheel observes; touchstart may cancel. Explicit options are clearer than relying on a target-specific default.

MDN documents that modern browsers other than Safari commonly default document-level wheel, touchstart, and touchmove listeners to passive. That is a compatibility behavior, not a reason to omit the option: use passive: false when cancellation is intentional and test the gesture on the browsers you support.

Hit testing finds the target

Hit testing asks which painted, eligible element is underneath a viewport coordinate. When an input must reach JavaScript, the main thread uses rendering information to find the event target before event dispatch follows capture, target, and bubble rules.

1const back = document.createElement("button");2back.textContent = "Pay";3back.style.cssText = "position:fixed;left:20px;top:20px;width:120px;height:60px";4 5const cover = document.createElement("div");6cover.style.cssText = "position:fixed;left:20px;top:20px;width:120px;height:60px;pointer-events:none";7 8document.body.append(back, cover);9console.log(document.elementFromPoint(40, 40)?.textContent);

Lines 1 through 4 build a button. Lines 5 through 7 build a cover directly over it, but the cover has pointer-events: none. Line 9 asks for the element at (40, 40) and prints Pay, because the cover is invisible to hit testing.

This is useful for decorative overlays, labels, and effects that should not block a real control beneath them. It does not remove the cover from the DOM or stop events that target another element from bubbling through ancestors in their normal way.

A component can also place its real control inside a shadow tree. Hit testing may find that inner control, while a listener outside the shadow tree can see event.target retargeted to the component host. That boundary keeps component internals private; use the event's composed path only when your component contract needs that extra detail.

Coalesced and predicted pointer events

Touch and pointer hardware can report movement more often than the display draws frames. Delivering every move to JavaScript would create too much hit testing and handler work. Browsers can merge several moves into one delivered pointermove near a frame.

1window.addEventListener("pointermove", (event) => {2  const points = event.getCoalescedEvents?.() ?? [event];3  const guesses = event.getPredictedEvents?.() ?? [];4  console.log("points", points.length);5  console.log("guesses", guesses.length);6});

Line 2 reads historical points with optional chaining, falling back to the delivered event. Line 3 asks for estimated future points only when that method exists. Lines 4 and 5 print the counts. The fallback makes the code safe in browsers that do not support one or both APIs.

getCoalescedEvents() returns earlier real points merged into this delivery and is valuable for a drawing path. Predicted events are estimates of future positions based on recent velocity and direction. They can reduce perceived drawing latency, but later real input can disagree.

1const rawMoves = [2  { x: 10, y: 10, time: 0 },3  { x: 14, y: 10, time: 4 },4  { x: 18, y: 10, time: 8 },5  { x: 22, y: 10, time: 12 },6];7 8const deliveries = coalesceRawMoves(rawMoves, 3);9console.log(deliveries.length);10console.log(deliveries[0].coalesced.length);11console.log(deliveries[0].delivered.x);

Lines 2 through 5 describe four raw moves. Line 7 groups them in threes. Line 8 prints 2 because two JavaScript deliveries are enough for four raw moves. Line 9 prints 3, and line 10 prints 18, the last point in the first delivered group.

In browser code, the delivered event is the final point and getCoalescedEvents() can provide the earlier positions. Draw every returned real point in order. Keep a predicted point separate, because the next actual delivery may require you to correct that temporary stroke.

1const event = { coalesced: 3, predicted: 1 };Run2 3function samplesFor(event) {4  return {5    points: event.coalesced,6    guesses: event.predicted,7  };8}9 10console.log(samplesFor(event));

Support is not uniform: MDN marks coalesced events as limited availability, and predicted events as newly available baseline support. Feature detection is therefore more honest than assuming every pointer event has these methods or returns the same number of samples.

Try the scroll-start model

Use this playground to change one decision at a time. Passive means the compositor may start scrolling right away in this model. “May cancel” means it waits for the stated main-thread busy time, because JavaScript could call preventDefault().

1const passive = true;2const mainThreadBusyMs = 40;3 4function startScroll(passive, mainThreadBusyMs) {5  return passive ? 0 : mainThreadBusyMs;6}7 8console.log(startScroll(passive, mainThreadBusyMs));

This is a teaching model rather than a profiler. It deliberately has only two inputs so the causal rule remains visible. On a real page, inspect the event type, listener options, target, CSS gesture policy, and a performance trace before deciding what caused jank.

Practical listener choices

Mark a listener passive when it only observes an event. A wheel analytics callback, a visual readout, or a listener that schedules ordinary work is often a good candidate. Write the option explicitly so a future reader does not depend on browser-specific default-passive behavior.

Keep a non-passive listener only when cancellation is truly required. For touch gestures, first ask whether touch-action can describe the browser gesture policy. CSS lets the browser know earlier than a JavaScript handler that it may need to stop or allow a pan.

Fix a janky scroll handler

Start with the smallest useful change. A cart preview that only observes wheel movement should not save data inside every wheel callback, and it should not leave the browser guessing whether the callback might cancel scrolling.

1window.addEventListener("wheel", (event) => {2  updateCartPreview(event.deltaY);3  saveCart();4  console.log("preview updated");5});

Line 1 gives no passive promise. Line 2 updates a preview, line 3 starts a save, and line 4 prints preview updated. Saving work on every wheel delivery can make the main thread busy even when the handler never calls preventDefault().

1window.addEventListener("wheel", (event) => {2  requestAnimationFrame(() => updateCartPreview(event.deltaY));3  console.log("preview scheduled");4}, { passive: true });

Line 2 batches the preview update for a rendering frame. Line 3 prints preview scheduled, and line 4 promises this listener will not cancel. Debounce or save after the gesture separately; passive avoids scroll-start waiting, but it does not make expensive work free.

Common misconceptions

• “Passive means no handler runs.” The handler runs normally; it simply cannot cancel the default action.
• “All scrolling waits for JavaScript.” Browsers can often scroll on the compositor when they have no cancellation reason to wait.
• “A cover always receives the event.” Hit testing skips a cover with pointer-events: none.
• “Predicted points happened already.” They are estimates and must not replace actual input history.

Practice exercises

const passive = true;
console.log(passive ? "scroll now" : "wait");

if (event.cancelable) event.preventDefault();

const target = document.elementFromPoint(x, y);

.cover { pointer-events: none; }

const points = [10, 15, 20];
console.log(points.length);

const points = event.getCoalescedEvents?.() ?? [event];

window.addEventListener("wheel", recordScroll, { passive: true });

Check your understanding

For each question, separate browser routing, cancellation permission, target selection, and the fidelity of pointer data.

Key takeaways

• The compositor can keep a scroll smooth when it has no reason to wait for a potentially canceling listener.
• A non-fast scrollable region represents work that may need main-thread confirmation before scroll starts.
• Passive means “I will not cancel”; preventDefault() in that listener is ignored.
• Hit testing finds the element beneath a coordinate, and pointer-events: none removes a visual cover from that search.
• Coalesced points are earlier real movement; predicted points are optional estimates.

Coming next: Bindings: how DOM objects exist in JavaScript.