Validate a parsed destination before an install action

A destination string should not become an executable or unexpected navigation merely because it is non-empty. This fixture parses a proposed URL and applies an explicit laboratory policy.

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: destination url is the governing reference for the browser primitive. MDN documents the URL constructor's parsing and relative-resolution behaviour. Parsing a URL establishes its structure; an application still needs a policy for which schemes and hosts it permits. The fixture policy around that primitive is ours.

The failure the fixture isolates

The corrected branch parses the input and accepts only HTTPS on one declared example host. The broken branch accepts any non-empty string. All addresses are inert fixtures and the code never navigates. The exact allowlist here is a teaching policy, not a store or network requirement.

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

A successful test proves that the validation branch rejects the supplied malformed or unapproved destinations. It does not establish the safety of a real destination's content, the correctness of an SDK redirect or whether a store-opening callback is permitted in a host environment.

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

Keep destination validation separate from the host-specific navigation adapter, and test that adapter with a stub before any real navigation. Record approved store URLs in build configuration and reject unexpected runtime substitutions. If several destinations are legitimate, make the rule explicit rather than weakening it to a substring check.

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.