User Activation Loss in Multi-Iframe Payment Flows

\n Browsers require user activation (a trusted click) for security-sensitive APIs like\n window.open(), fullscreen, clipboard, and payment requests. Async operations between\n a click and these API calls can cause the browser to lose the activation context — silently breaking\n the payment flow. This page demonstrates why JPM's current two-iframe architecture is at risk and\n how a single-iframe approach eliminates it.\n

\n\n \n

Architecture Comparison

Current: JPM Two-Iframe Architecture

ACTIVATION User activation from original click does not transfer to Iframe B — it's a new browsing context
ACTIVATION Async gap (postMessage + SDK init) can exceed browser timeout, breaking activation-gated APIs
LATENCY SDK initializes twice — double network requests, double startup time
REDUNDANT Two SDK instances in the same session consume extra memory and add unnecessary overhead

\n\n

Proposed: Single-Iframe Architecture

User clicks \"Pay with Klarna\"\n |\n [Iframe] — has SDK (already initialized)\n |\n postMessage: \"expand iframe\" ← sync-ish\n |\n [Parent] expands same iframe\n |\n SDK calls initiate({ ON_PAGE })\n |\n Popup opens (window.open) + overlay shown

Same browsing context — user activation stays in the iframe where the click happened
Single SDK instance — already initialized when user clicks, no re-init delay
ON_PAGE mode — popup opens via window.open() with user activation intact, overlay protects the merchant page
Minimal async gap — only the parent iframe resize, not a full SDK bootstrap

\n\n \n

Why User Activation Matters

\n The Klarna Web SDK's default interaction mode is DEVICE_BEST, which resolves to\n ON_PAGE on desktop/mobile and REDIRECT in webviews.\n ON_PAGE mode always opens a popup via window.open() —\n the overlay shown on the merchant page simply protects the site from interaction while the popup is open.\n This means window.open() is called every time a user initiates a payment, and it\n requires valid user activation or the browser will block it.\n

\n The core problem: In JPM's two-iframe architecture, the user clicks in Iframe A, but the\n SDK that needs to act on that click runs in Iframe B. User activation is per-frame — it does\n not propagate across iframe boundaries. Iframe B never had a user click, so it has no activation.\n

\n\n \n

Interactive Evidence: Async Operations Break User Activation

\n Click each button to test whether window.open() succeeds. This proves that async\n operations between a click and an activation-gated API call cause browsers to block the call.\n Try in Safari for the most dramatic results.\n

\n\n

\n \n

Test 1: Synchronous (baseline)

Click handler calls window.open() directly — no async gap.

button.addEventListener('click', () => {\n  window.open('about:blank');\n});

\n \n

Expected: Allowed in all browsers

\n\n \n

Test 2: setTimeout(fn, 0)

Defers to a new macrotask — like postMessage handler receiving a response.

button.addEventListener('click', () => {\n  setTimeout(() => {\n    window.open('about:blank');\n  }, 0);\n});

\n \n

Expected: Allowed — 0ms is too fast to lose activation

\n\n \n

Test 3: await (configurable delay)

Simulates waiting for an async operation. Adjust the delay to find your browser's blocking threshold.

\n Delay (ms): \n

button.addEventListener('click', async () => {\n  await new Promise(r => setTimeout(r, delay));\n  window.open('about:blank');\n});

\n \n

Expected: Blocked in Safari (>=1000ms), blocked Chrome/Firefox (~5000ms)

\n\n \n

Test 4: JPM's Flow (postMessage + SDK init)

Simulates JPM's actual architecture: click in iframe A → postMessage to parent → parent creates iframe B → SDK initializes in B → window.open().

\n SDK init time (ms): \n

// Iframe A: click handler\nbutton.addEventListener('click', () => {\n  parent.postMessage('create-iframe-b');\n});\n// Parent: creates Iframe B, loads SDK\n// Iframe B: SDK initializes (1-3s)...\n// Iframe B: SDK calls window.open()\n// ❌ No user activation in Iframe B!

\n \n

Expected: Blocked — user activation doesn't transfer to new iframe

\n\n \n

Test 5: Proposed Flow (same-frame, small wait)

Simulates the single-iframe proposal: click → tell parent to expand → small wait for reflow → initiate in same frame.

button.addEventListener('click', async () => {\n  parent.postMessage('expand-iframe');\n  await new Promise(r => setTimeout(r, 50));\n  // Same frame — activation still valid\n  window.open('about:blank');\n});

\n \n

Expected: Allowed in Chrome/Firefox (within 5s), may be blocked Safari

\n\n \n

Test 6: Cross-Iframe Activation Transfer

Creates a new iframe and tries to call window.open() from it — proving activation does NOT transfer across frames.

button.addEventListener('click', () => {\n  const iframe = document.createElement('iframe');\n  iframe.srcdoc = `<script>\n    window.open('about:blank');\n  </script>`;\n  document.body.appendChild(iframe);\n});

\n \n

Expected: Blocked — new iframe has no user activation

\n\n \n

Live: User Activation State

\n The navigator.userActivation API shows the browser's internal activation tracking in real time.\n Click anywhere, then watch the transient activation expire.\n

\n Click anywhere to see activation state...\n

\n\n \n

Browser User Activation Models

\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n

Aspect	Chrome (72+)	Firefox	Safari
Activation model	Timestamp-based (User Activation v2)	Timestamp-based	Call-stack-based
Transient activation timeout	5 seconds	5 seconds	~1 second
`setTimeout(fn, 0)` then API call	Allowed	Allowed	Allowed
Async delay ≥1s then API call	Allowed (if <5s)	Allowed (if <5s)	Blocked
API call in synchronous click handler	Allowed	Allowed	Allowed
Activation transfers across iframes	No	No	No

\n\n

\n Key takeaway for JPM's two-iframe architecture:\n

\n The fundamental issue is not just timing — it's that user activation is per-frame.\n When the user clicks in Iframe A (the button iframe), that activation exists only in Iframe A.\n When JPM creates Iframe B (the fullscreen payment iframe) and initializes a new SDK instance there,\n Iframe B has zero user activation regardless of timing. Any activation-gated API call\n the SDK makes in Iframe B will be blocked.\n

\n ON_PAGE mode always calls window.open() to open the Klarna payment popup\n (the overlay simply protects the merchant page from interaction). Since window.open() is\n activation-gated, it will be blocked in Iframe B which has no user activation.\n

\n\n

\n Why the single-iframe architecture solves this:\n

\n In the proposed architecture, the SDK is already initialized in the same iframe where the user clicks.\n The only async operation is telling the parent to resize the iframe (a fast postMessage + CSS change).\n The SDK's initiate() call happens in the same browsing context where the\n click occurred, so user activation is preserved when the SDK calls window.open() to open\n the payment popup. On Chrome/Firefox, the 5-second timestamp window is more than enough for the\n iframe resize before the popup opens.\n

\n\n

Authoritative Sources

WHATWG HTML Spec — Tracking User Activation — Defines transient activation, per-frame scoping, and activation-consuming APIs
MDN — Features gated by user activation — Lists all activation-gated APIs including window.open()
Chrome Blog — User Activation v2 — Frame-scoped, timestamp-based model (5s expiry)
MDN — Window.open() — \"Popup windows must be opened in direct response to user input\"
Chromium source: kActivationLifespan = base::Seconds(5) in user_activation_state.h
Firefox config: dom.user_activation.transient.timeout = 5000 (configurable via about:config)

\n\n \n \n\n","deleted","label",[182,166],"frontend","permalink","https://www.val.town/x/klarnapublic/JPM-setup/code/frontend/popup-blocking-demo.html","extension","html","actionData","errors"]