Wheel event momentum

at a glance

Member reference

The developer-facing surface is exactly two items, documented together on one stable page with all nine dimensions (syntax, inputs, outputs, errors, context, lifecycle, examples, compatibility, and security/privacy):

• WheelEvent.momentum — true when the platform synthesized the event to simulate scroll inertia after the physical interaction ended
• WheelEventInit.momentum — the matching constructor dictionary member (defaults to false)

Why it exists

Trackpads fling: the physical gesture ends, but the OS keeps the scroll gliding with synthesized wheel events. Pages that react to every wheel event — carousels, maps, custom scrollers — cannot tell these inertia events from real user input, so they keep responding after the user has let go. A boolean on the event itself ends the guessing games (velocity heuristics, timeouts): when momentum is true, the event was synthesized by the platform to simulate inertia; when false, the spec says only “otherwise” — it does not establish physical input (a script-constructed event also initializes to false, and uninstrumented platforms report false throughout).

Runtime qualification: in Chromium the value is mapped from the platform event as momentum_phase != kPhaseNone (the Blink unit test injects kPhaseBegan /kPhaseChanged /kPhaseNone to pin the mapping). The implementation CL records that manual testing on Linux did not surface the value in JS — “maybe because of platform limitations” — and landed with extra tracing to investigate other platforms in Dev/Canary builds. Real hardware/OS behavior (which platforms and devices actually emit momentum phases) therefore needs Chrome 151+ hardware evidence; this reference does not claim it.

Examples

// Stop a custom scroller from reacting to inertia-only events.
scroller.addEventListener("wheel", (event) => {
  if (event.momentum) return; // platform inertia after the fling — ignore
  event.preventDefault();
  scroller.scrollBy(0, event.deltaY);
}, { passive: false });

// Feature-detect before relying on it:
const supported = "momentum" in WheelEvent.prototype;

Browser compatibility

Support rows are from BCD only. Separately, vendor signals come from the ChromeStatus API feature record (checked 2026-07-26): Firefox “Positive”, Safari “No signal”, web developers “Positive” (as labelled on the ChromeStatus feature entry). There is no behavioral WPT test for momentum as of 2026-07-26: the pinned tree at commit 1985b47 contains exactly two momentum declarations — the WebIDL surface itself in interfaces/pointerevents.idl (lines 90 and 98) — and no behavioral .html/.js test was found.

Specifications

Note: the ChromeStatus entry's spec link anchors to #dom-wheelevent-momentum and BCD's spec link anchors to #dom-wheeleventinit-momentum — neither resolves in the current draft (the attribute has no dedicated anchors); the resolvable section is #interface-wheelevent (linked above and throughout this reference).

See also

• crbug.com/40704952 — implementation tracking; Chromium runtime_enabled_features.json5 (WheelEventMomentum, stable)
• Sample — CodePen demo (from the ChromeStatus entry)
• MDN — WheelEvent (general interface; no momentum coverage as of 2026-07-26)
• Chrome Platform Showcase — Wheel event momentum (also: feature detect)