Why would you add { passive: true } to a scroll or touchstart listener, and what problem does it solve for scroll performance?

Question presented to candidate: "You add a touchstart listener to track gesture analytics. Users report scrolling feels janky on mobile after you added it, even though your listener does almost nothing. Why, and how would you fix it?"

What a strong answer should cover:

• 📌 Interview term: the real, direct answer to the prompt — by default, the browser genuinely cannot start scrolling in response to a touch gesture until it has first RUN every registered touchstart/touchmove listener to completion, because any one of them COULD call .preventDefault() to cancel the scroll — even an empty or near-empty listener genuinely introduces a real, measurable delay before scrolling can begin.
• 📌 Interview term: { passive: true } — a real, third-argument option to addEventListener that tells the browser, in advance, "this listener will never call preventDefault()" — letting the browser genuinely start scrolling immediately, in parallel, without waiting for the listener to finish running at all.
• 📌 Interview term: the real, verified consequence of the promise — verified directly: calling .preventDefault() INSIDE a listener registered with { passive: true } genuinely does NOT throw — the browser silently ignores the call — but it genuinely has ZERO effect, confirmed directly (event.defaultPrevented stayed false even after the call) — the browser is trusting the passive promise was kept, and does not even check.
• 📌 Interview term: the real fix for the prompt's exact scenario — a precise answer names that adding { passive: true } to the touchstart listener (since the analytics tracking genuinely never needs to cancel the gesture) genuinely removes the real, measurable scroll-blocking delay — the browser can start scrolling the instant the touch begins, running the analytics listener in parallel rather than beforehand.
• A precise answer names that several browsers have made touchstart/touchmove listeners genuinely default to { passive: true } UNLESS explicitly marked { passive: false } — a real, deliberate platform-level mitigation for exactly this common performance footgun — but relying on that default rather than being explicit is a real, honest gap in guaranteed cross-browser behavior worth naming.

Clarifying questions expected:

• None — this is a definitional/practical question; directly diagnosing the prompt's own reported jank with real, verified proof is the strong signal.

Code / implementation expected: Yes — a real, direct demonstration that calling preventDefault() inside a { passive: true } listener neither throws nor has any effect.