A custom slider tracks a drag with pointerdown on the thumb plus pointermove and pointerup on the same element. The drag stops updating as soon as the pointer moves off the thumb. What does Element.setPointerCapture() change, and what else must the handler deal with?

## Why the drag freezes Pointer events are dispatched to the element under the pointer, decided by hit-testing on each move. That is fine for hover, and wrong for dragging: during a drag the user's intent is bound to the element they *grabbed*, not to whatever happens to be under the cursor a moment later. Move a few pixels off the slider thumb — onto the track, onto the page, onto a neighbouring widget — and the `pointermove` events go there instead. The slider stops following the finger, and if the button is released off-target, the `pointerup` handler on the thumb never runs, so `isDragging` stays true and the next stray move resumes the drag. Touch behaves differently, which is a common source of "it works on my phone" confusion: for direct-manipulation pointers the browser applies **implicit pointer capture** at `pointerdown`, so a touch drag already stays with the original element. Mouse and pen do not get that. ## The historical fix and its costs The pre-capture pattern was to attach `mousemove` and `mouseup` to `document` (or `window`) on mousedown and remove them on mouseup. It works, but it spreads one interaction across three targets, requires disciplined teardown, and any thrown exception mid-drag leaves global listeners installed. It also interacts badly with iframes and with other widgets that listen on the document. ## What setPointerCapture does `Element.setPointerCapture(pointerId)` declares that the given active pointer belongs to that element. From then on, every event for that `pointerId` is dispatched **to the capturing element** regardless of hit-testing, and boundary events are computed against it too. The API surface is small and worth naming exactly: - `element.setPointerCapture(pointerId)` — claim the pointer; it must be an *active* pointer or the call throws a `NotFoundError`. - `element.releasePointerCapture(pointerId)` — release early. - `element.hasPointerCapture(pointerId)` — query the current state. - The `gotpointercapture` and `lostpointercapture` events fire on the element when capture is acquired and released. Capture is released **implicitly** when the pointer goes up or is cancelled, so most code never calls `releasePointerCapture` at all. ```js thumb.addEventListener('pointerdown', (event) => { if (!event.isPrimary) return; thumb.setPointerCapture(event.pointerId); dragging = true; }); thumb.addEventListener('pointermove', (event) => { if (!dragging) return; const rect = track.getBoundingClientRect(); setValue((event.clientX - rect.left) / rect.width); }); const end = () => { dragging = false; }; thumb.addEventListener('pointerup', end); thumb.addEventListener('pointercancel', end); ``` Every listener lives on the element it belongs to, there is nothing to install or remove globally, and the events keep arriving while the pointer is anywhere over the page. ## The three things that still bite **1. `pointercancel` has no `pointerup`.** The browser fires `pointercancel` when it takes the gesture over — it decided the movement is a scroll or pinch, the pointer left the device's range, or the OS interrupted. There is no `pointerup` afterwards, so any state reset that only lives in the `pointerup` handler is skipped and the widget stays stuck mid-drag. Wire both to the same teardown, as above. **2. `touch-action` decides whether you get the gesture at all.** By default the browser may treat a touch drag on your thumb as a page pan, in which case it claims the gesture and cancels your pointer partway through. Declaring `touch-action: none` on the thumb (or `pan-y` if the page should still scroll vertically) tells the browser up front that the element owns those gestures, so the pointer stream is not cut short. Capture without this is the classic "works with a mouse, dies under a finger" bug. **3. Capture does not extend past the document.** It keeps events flowing within the capturing document; it is not a licence over the whole OS. Releasing the button outside the browser window may not produce a `pointerup` you can see, so a robust widget also resets on `blur` or when `event.buttons` shows no button is pressed any more. ## Multi-touch and pointerId `pointerId` is what makes capture composable: two fingers on two different sliders each capture their own pointer, and each element sees only its own stream. A single-pointer widget should still bail out on non-primary pointers with `if (!event.isPrimary) return;`, otherwise a second finger anywhere on the element starts a competing drag. ## What an interviewer is listening for That you can name *why* the drag broke — hit-test routing, no implicit capture for mouse — rather than reciting the API; that you reach for capture instead of document-level listeners and can say what that buys; and that you mention `pointercancel` and `touch-action` unprompted, because those are the two things that separate a demo from a slider that survives real devices.