v136 · user input

Dispatching click events to captured pointer

If a pointer is captured while the `pointerup` event is being dispatched, the `click` event will be dispatched to the captured target instead of the nearest common ancestor of `pointerdown` and `pointerup` events as per the UI Event spec.

concepts

  1. Captured Click

    When a pointer is captured, the eventual click event fires on the capture target, not the elementFromPoint. Removes a class of drag-handle bugs.

  2. Slider thumb drag

    The real-world UI that motivated the fix: a custom slider thumb that captures the pointer. Drag off-track and release — pre-136 the click escapes to body, 136+ it stays on the thumb.

  3. Drawing Canvas

    Pen + toolbar: capture the pointer for the whole stroke for smooth drawing across element boundaries, and still get a real click on the tool button. The event log shows what fires when.

  4. Paint with capture

    A full painting app using setPointerCapture() — strokes stay on-canvas when the pointer moves off. The event log highlights each click event fired on the canvas (the Chrome 136 fix), enabling colour-picker taps and tool selection to work correctly during capture.

why it shipped

PEWG agreed to this new behavior after a multi-year deliberation [1] and updated the PointerEvents spec in 2023 [2]. The primary motivation for this decision is to make click targets more developer-friendly when pointer-capture. Note that the original "nearest common ancestor" targeting was defined in the UI Event spec many years before the pointer-capture concept was avalable.

references