Let one pointer finish the drag it started

A second touch should not steal an object already being dragged. This fixture makes pointer ownership explicit and checks that unrelated move events cannot alter the active interaction.

This edition is a laboratory fixture. Node and the companion HTML page execute the authored functions against synthetic cases. No physical device panel was run, no ad network reviewed the build, and no campaign result is inferred from a passing test.

What the documentation actually supplies

MDN: pointer owner is the governing reference for the browser primitive. MDN describes pointerId as the identifier for the pointer that generated an event, distinct from other active pointers. It cautions against interpreting that identifier as a permanent device identity. The fixture policy around that primitive is ours.

The failure the fixture isolates

The first input is the active pointer ID, followed by candidate move events. The corrected branch accepts moves only from that owner. The broken branch accepts the last movement from any pointer. The resulting coordinate reveals whether another finger can unexpectedly move the object.

The broken branch is retained so a producer can see the exact mistake, not only the repaired output.

All 3 fixed-branch cases matched the spec when executed in Node on 19 September 2026.

What a pass does not prove

The tests exercise event-selection logic using synthetic pointer records. They do not establish browser pointer capture, gesture arbitration or behaviour after a real pointer cancellation. A production handler still needs explicit release and cancellation paths so an interrupted drag cannot leave ownership permanently locked.

Untested cells in this edition: physical devices, host SDKs, network packaging limits, store-opening callbacks, and campaign performance. Those remain empty on purpose.

Next check on a real build

Integrate the owner check with the actual event lifecycle, then use a real touch-capable environment to start a drag and introduce another contact. Verify pointerup and pointercancel independently. Keep a keyboard path for essential controls rather than treating pointer IDs as the only possible source of activation.

Open the runnable fixture to re-execute the cases in a browser. Download the case record to keep inputs, expectations and limits with a QA ticket.

Background in the archive: Playable ad device testing matrix and Playable spec sheet before you build. Those guides describe practice; they are not a substitute for this fixture and this check does not recertify their every claim.