WebView Escape Tests

Open this page from Instagram/Facebook/Threads to test each escape method.

Your UA:

WebView detected:

iOS Escape Methods

x-safari- Meta Refresh (ninja.link)

Server-side <meta http-equiv="refresh"> — no JS needed

googlechromes:// (Bouncy)

JS-based Chrome scheme — requires Chrome installed

NATIVE <a href="x-safari-..."> TAP ★★★

Creates an actual <a> tag with x-safari href from API. You physically tap the link. WKWebView treats this as .linkActivated — might work.

SERVER 302 → x-safari ★★★

Server responds with HTTP 302 Location: x-safari-https://... No JS involved at all.

Runtime x-safari (window.location) — BLANKS

Confirmed: blanks page even with runtime URL

Runtime window.open(x-safari) — stays in WebView

Confirmed: strips scheme, opens page inside WebView

Runtime window.open (WORKED - opens Chrome)

Confirmed: fetches URL from API, window.open opens in Chrome (default browser).

Age gate + full chain (no pixel)

x-safari(100ms) → window.open(600ms) → googlechromes(1200ms) → hold(2500ms)

Full Bouncy Replica (with Pixel)

Same as above but WITH Meta Pixel. May show blank in FB WebView.

x-safari- + Meta Pixel (NEW)

Loads fbevents.js SDK first, fires Lead event, then x-safari-. Tests MobileAppBridge trust theory.

window.open() ONLY

Just window.open(url, '_blank')

Bouncy's exact combo

x-safari-(100ms) + window.open(600ms) + beforeunload handler

x-safari- via JS (window.location.href)

Direct JS — FAILED in FB WebView on previous test

x-safari- via <a href> (native link)

No JS, just a native <a> tag with x-safari- href

x-safari- via window.open

window.open('x-safari-...', '_blank') on click

x-safari- via setTimeout (Bouncy pattern)

setTimeout(100ms) after click — matches Bouncy's exact code path

Triple Fallback (our proposed)

x-safari → googlechromes:// (500ms) → press-hold (1.5s)

Android Escape

intent:// Chrome + auto-close

Chrome Intent URL with visibilitychange auto-close

Direct (no escape)

Direct link (no escape)

Standard navigation — stays in WebView