Require both intersection and document visibility before advancing

An element can remain geometrically inside a viewport while its document is hidden. This fixture checks a deliberately simple activity gate that requires both conditions.

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: viewability gate is the governing reference for the browser primitive. MDN describes Intersection Observer as asynchronously observing a target's intersection with an ancestor or viewport. Intersection is a geometric signal; this fixture does not interpret it as a certified impression or billable viewability event. The fixture policy around that primitive is ours.

The failure the fixture isolates

The laboratory uses an illustrative intersection threshold of one half and a separate visible flag. The broken branch checks the ratio alone. The corrected branch requires both signals, showing why a single convenient visibility-like number should not silently control the whole playable lifecycle.

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 threshold is a teaching choice, not an ad-network rule. A passing function demonstrates Boolean gating for supplied inputs, not a physical visibility observation. Occlusion, host lifecycle events and the measurement definition used by a network remain outside this test.

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

In an actual integration, document which signals are authoritative for activity and which are only diagnostic. Feed them into one state transition rather than allowing several listeners to start and stop independent loops. Record why the state changed so an apparently frozen playable can be traced to its input conditions.

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.