Count one install action when the end card is tapped repeatedly

A double tap on an end card should not dispatch duplicate store-opening actions. This fixture uses a real EventTarget to check a once-only handler while keeping every action inside the laboratory.

This article 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: cta once is the governing reference for the browser primitive. MDN documents addEventListener and its once option, which removes a listener after its first invocation. That controls a listener's lifecycle; the surrounding application still owns when a new end-card session begins. The fixture policy around that primitive is ours.

The failure the fixture isolates

Both branches dispatch repeated synthetic click events to a local EventTarget. The fixed branch registers the listener with once enabled, while the broken branch increments on every dispatch. The counter stands in for a host action: no store, browser tab or network endpoint is opened.

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

Passing this test proves one listener fires once for the supplied event sequence. It does not prevent a different listener from dispatching the same business action, and it does not validate an ad SDK's click API. An application-level idempotency guard may still be appropriate when several activation paths share one action.

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

Next check on a real build

Trace mouse, touch, keyboard and host callbacks to one install-action boundary. Define whether restarting the playable creates a new eligible action, then reset deliberately at that boundary. Test the real integration with a stubbed host opener before trying an authorised store-opening path.

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.