[{"_1":2,"_3":-5,"_4":-5},"loaderData",{"_5":6,"_7":8,"_9":10},"actionData","errors","root",{"_298":299,"_300":301},"routes/_app.x.$handle.$name",{"_100":99,"_32":45,"_108":90,"_27":109,"_13":14,"_110":-5,"_11":111,"_112":113,"_114":115,"_116":117,"_118":119,"_20":-5,"_120":-5,"_121":-5,"_122":25,"_123":124,"_125":59,"_126":-5,"_127":-5,"_128":129},"routes/_app.x.$handle.$name.branch.$branch.version.$version.diff",{"_11":12,"_13":14,"_15":16,"_17":-5,"_18":-5},"project",{"_43":44,"_32":45,"_38":46,"_47":-5,"_48":25,"_49":50,"_51":50,"_52":53,"_54":-5,"_18":55,"_56":57,"_58":59,"_60":-5,"_61":-5,"_62":63,"_64":65,"_66":67,"_68":69,"_70":71,"_72":-5,"_73":74,"_75":74,"_76":77,"_78":77,"_79":77,"_80":74,"_81":74,"_82":83,"_84":85,"_86":87,"_88":25},"version",90,"changes",[19],"aiChatInfo","userId",{"_20":21,"_22":23,"_24":25,"_26":25,"_27":28,"_29":28},"file",{"_30":31,"_32":33,"_34":20,"_35":37,"_38":39,"_40":14,"_41":42,"_24":25},"previous",{"_30":31,"_32":33,"_34":20,"_35":36},"deleted",false,"deletedHere","path","frontend/popup-blocking-demo.html","latestPath","fileId","cbfe16ec-2399-11f1-8e70-42dde27851f2","name","popup-blocking-demo.html","fileType","content","\n\n \n \n \n User Activation & Async Operations — Evidence for JPM Integration\n \n \n \n

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 Payment overlay renders in-place

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 — overlay renders inside the iframe, no popup needed
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 popup-based on desktop and redirect in webviews. Even when using\n ON_PAGE mode, the SDK may internally require user activation for fallback scenarios.\n If the SDK ever needs to call window.open() (e.g., for 3DS verification, bank redirects,\n or fallback flows), the browser will block it if user activation has been lost.\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: Blocked in Safari, allowed Chrome/Firefox (within 5s)

\n\n \n

Test 3: await (configurable delay)

Simulates waiting for an async operation. Adjust delay to find your browser's 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 (any delay), blocked Chrome/Firefox (>5s)

\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	~0-1 second (same-tick only)
`setTimeout(fn, 0)` then API call	Allowed	Allowed	Blocked
`await fetch()` 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 Even with ON_PAGE mode, the SDK internally uses activation-gated APIs. If the SDK ever\n needs to open a popup for 3DS verification, bank redirects, or fallback flows, it will fail silently\n in Iframe B.\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. On Chrome/Firefox, the 5-second timestamp window\n is more than enough. On Safari, the ON_PAGE overlay renders without needing window.open(),\n so call-stack activation isn't required.\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","\n\n \n \n \n User Activation & Async Operations — Evidence for JPM Integration\n \n \n \n

User Activation Loss in Multi-Iframe Payment Flows

\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

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\n \n

Interactive Evidence: Async Operations Break User Activation

\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: Blocked in Safari, allowed Chrome/Firefox (within 5s)

\n\n \n

Test 3: await (configurable delay)

Simulates waiting for an async operation. Adjust delay to find your browser's 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 (any delay), blocked Chrome/Firefox (>5s)

\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	~0-1 second (same-tick only)
`setTimeout(fn, 0)` then API call	Allowed	Allowed	Blocked
`await fetch()` 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","createdAt",["D",1773929208226],"branchVersion","branchId","2c36ce54-00e6-11f1-a76a-42dde27851f2","id","2c36560e-00e6-11f1-a76a-42dde27851f2","JPM-setup",["D",1770112400938],"deletedAt","legacyEnvVars","privacy","public","httpPrivacy","description","How to limit usage to one iframe of initializing Klarna Web SDK","imageUrl","01993d45-9433-727b-b29b-06a7295b5411","pinnedFileId","6d78e38c-00ed-11f1-bb4f-42dde27851f2","pinPreview",true,"pinMigrated","screenshotVersion","likeCount",0,"orgId","01993d45-9433-727b-b29b-099b638de562","tursoName","2c36560e00e611f1a76a42dde27851f2","tursoHostname","2c36560e00e611f1a76a42dde27851f2-val-town.aws-us-east-2.turso.io","tursoMeasuredAt",["D",1789518676100],"pinned","userPerm","r","valPerm","blobPerm","rw","emailPerm","sqlitePerm","projectPerm","telemetryPerm","user",{"_100":99,"_107":103},"org",{"_100":99,"_101":-5,"_102":103,"_18":55,"_104":105,"_106":25},"branch",{"_13":89,"_32":90,"_43":42,"_91":44,"_92":-5,"_93":-5,"_94":-5,"_95":-5,"_96":-5,"_97":45,"_98":99},"isOwned",101,"main","projectId","forkedBranchId","forkedBranchVersion","forkedProjectPrivacy","forkedProjectId","forkedProjectOrgId","projectName","userHandle","alexanerstalbrandklarna","handle","displayName","avatar","https://img.clerk.com/eyJ0eXBlIjoiZGVmYXVsdCIsImlpZCI6Imluc18yTm10cGhQUklwU0tqZHNiOHNnNGd2ZjJURFUiLCJyaWQiOiJ1c2VyXzMyYXJhOVozMGlPajdzS20yR0RiaTREMDZ3bCJ9","tier","free","canRestrictVals","profileImageUrl","branchName","","adoptOrgId",{"_43":44,"_32":45,"_38":293,"_47":-5,"_48":25,"_49":50,"_51":50,"_52":53,"_54":-5,"_18":55,"_56":57,"_58":59,"_60":-5,"_61":-5,"_62":63,"_64":65,"_66":67,"_68":69,"_70":294,"_72":-5,"_73":74,"_75":74,"_76":77,"_78":77,"_79":77,"_80":74,"_81":74,"_82":295,"_84":296,"_86":297,"_88":25},"tree",[207,209,214,216,217,218,219,220],"files",[207,208,209,210,211,212,213,214,215,216,217,218,219,220],"counts",{"_197":63,"_198":161,"_199":161,"_200":201,"_202":203},"contents",[130,131,132,133,134,135,136,137],"upstreamProject","upstreamBranch","emptyEnvVars","flags",[],"hasHttpFiles","grants","orgs","customDomains",{},{"_43":191,"_32":192,"_30":193,"_140":-5,"_41":42,"_40":194,"_142":59,"_38":195,"_13":63,"_34":183,"_35":-5,"_24":25,"_147":-5,"_27":196},{"_43":185,"_32":186,"_30":187,"_140":-5,"_41":42,"_40":188,"_142":59,"_38":189,"_13":63,"_34":183,"_35":-5,"_24":25,"_147":-5,"_27":190},{"_43":178,"_32":179,"_30":180,"_140":-5,"_41":42,"_40":181,"_142":59,"_38":182,"_13":63,"_34":183,"_35":-5,"_24":25,"_147":-5,"_27":184},{"_43":171,"_32":172,"_30":173,"_140":-5,"_41":42,"_40":174,"_142":59,"_38":175,"_13":63,"_34":20,"_35":176,"_24":25,"_147":-5,"_27":177},{"_43":164,"_32":165,"_30":166,"_140":-5,"_41":42,"_40":167,"_142":59,"_38":168,"_13":63,"_34":20,"_35":169,"_24":25,"_147":-5,"_27":170},{"_43":156,"_32":157,"_30":158,"_140":-5,"_41":42,"_40":159,"_142":59,"_38":160,"_13":161,"_34":20,"_35":162,"_24":25,"_147":-5,"_27":163},{"_43":149,"_32":150,"_30":151,"_140":-5,"_41":42,"_40":152,"_142":59,"_38":153,"_13":63,"_34":20,"_35":154,"_24":25,"_147":-5,"_27":155},{"_43":138,"_32":139,"_30":57,"_140":-5,"_41":42,"_40":141,"_142":25,"_38":143,"_13":144,"_34":145,"_35":146,"_24":25,"_147":-5,"_27":148},"230b1d72-239a-11f1-a362-42dde27851f2","main.ts","parentId",87,"latest",["D",1773928034466],5,"http","import {\n readFile,\n serveFile,\n} from \"https://esm.town/v/std/utils@85-main/index.ts\";\n\nexport default async function (req: Request) {\n const url = new URL(req.url);\n const path = url.pathname;\n\n // Serve frontend files\n if (path.startsWith(\"/frontend/\")) {\n return serveFile(path, import.meta.url);\n }\n\n // Popup blocking demo at top-level path\n if (path === \"/popup-blocking-demo\" || path === \"/popup-blocking-demo.html\") {\n return serveFile(\"/frontend/popup-blocking-demo.html\", import.meta.url);\n }\n\n // Serve shared files\n if (path.startsWith(\"/shared/\")) {\n return serveFile(path, import.meta.url);\n }\n\n // Main page (first-party context)\n const html = await readFile(\"/frontend/index.html\", import.meta.url);\n return new Response(html, {\n headers: { \"Content-Type\": \"text/html\" },\n });\n}\n","label",[139],"f54e8f72-00e9-11f1-a3d1-42dde27851f2","deno.json","f54e904e-00e9-11f1-a3d1-42dde27851f2",10,["D",1770114026808],"{\n \"$schema\": \"https://raw.githubusercontent.com/denoland/deno/98f62cee78e85bfc47c62ed703777c6bc8794f1c/cli/schemas/config-file.v1.json\",\n \"lock\": false,\n \"compilerOptions\": {\n \"noImplicitAny\": false,\n \"strict\": true,\n \"types\": [\"https://www.val.town/types/valtown.d.ts\"],\n \"lib\": [\n \"dom\",\n \"dom.iterable\",\n \"dom.asynciterable\",\n \"deno.ns\",\n \"deno.unstable\"\n ]\n },\n \"lint\": {\n \"include\": [\"deno:/https/esm.town/**/*\"],\n \"rules\": {\n \"exclude\": [\"no-explicit-any\"]\n }\n },\n \"node_modules_dir\": false,\n \"experimental\": {\n \"unstable-node-globals\": true,\n \"unstable-temporal\": true,\n \"unstable-worker-options\": true,\n \"unstable-sloppy-imports\": true\n }\n}",[150],"dd78a232-1180-11f1-908f-42dde27851f2","CLAUDE.md","b5798410-117e-11f1-bf22-42dde27851f2",51,["D",1771938059261],1,"# CLAUDE.md\n\nThis file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.\n\n## Project Overview\n\nThis is a **Val Town project** — a Klarna payment integration prototype demonstrating iframe-based payment flows for the JPM (J.P. Morgan) partnership. It runs on the Val Town platform (Deno serverless runtime, not Node.js).\n\n## Running the Project\n\nThis project is deployed and run via Val Town. Locally, use the `vt` CLI:\n\n```bash\nvt dev # Start local dev server\nvt push # Deploy to Val Town\nvt pull # Pull latest from Val Town\n```\n\nThe project has a `.vt/state.json` that tracks the Val Town project ID and branch.\n\n## Architecture\n\nThe app uses a **single-iframe architecture** for Klarna payment integration:\n\n1. **`main.ts`** — HTTP request handler (Val Town entry point). Serves static files from `frontend/` and `shared/` using Val Town's `serveFile`/`readFile` utilities.\n\n2. **`frontend/index.html`** — First-party merchant page. Embeds a single `\n \n \n\n \n

Payment Status

\n \nWaiting for payment...\n

\n \n\n \n \n\n",[],[186,272],["D",1770114025840],[210,211,212,213],[186],"d2ffec40-130e-11f1-b43d-42dde27851f2","settings.local.json","78d7359c-117f-11f1-96b3-42dde27851f2",81,["D",1772108981555],"{\n \"permissions\": {\n \"allow\": [\n \"Bash(grep:*)\",\n \"Bash(find:*)\",\n \"Bash(npx jest:*)\"\n ]\n }\n}\n",[],[192,283],["D",1771937460882],[208],[192],["D",1770112400938],["D",1789518676100],{"_100":99,"_107":103},{"_100":99,"_101":-5,"_102":103,"_18":55,"_104":105,"_106":25},{"_13":89,"_32":90,"_43":42,"_91":44,"_92":-5,"_93":-5,"_94":-5,"_95":-5,"_96":-5,"_97":45,"_98":99},"ctx",{"_82":-5,"_127":331,"_332":333,"_334":335,"_336":25,"_337":25,"_338":25,"_339":59,"_340":-5,"_341":-7,"_342":-7,"_343":63,"_344":25,"_345":25,"_346":-5,"_347":25,"_348":25,"_349":25,"_350":-5},"ENV",{"_302":303,"_304":305,"_306":90,"_307":308,"_309":310,"_311":312,"_313":314,"_315":316,"_317":318,"_319":320,"_321":322,"_323":324,"_325":326,"_327":328,"_329":330},"REACT_APP_SENTRY_DSN","https://586020d86f05489db63a554690acf1e9@o1398359.ingest.sentry.io/6724499","RENDER_GIT_COMMIT","e87eb04e707cf64e7e532c8e8ec395f209e17f15","RENDER_GIT_BRANCH","POSTHOG_API_TOKEN","phc_nmoyuAkStEZuUp69rYlg1DZgrIt19Gx0Y4Hwf8tGgJP","POSTHOG_API_HOST","https://wart.val.town","WEB_API_TEMPLATE","https://{val}.web.val.run","APP_URL","https://www.val.town","MODULE_URL","https://esm.town","VANITY_WEB_API_TEMPLATE","https://{label}.val.run/","DENOLS_URL","https://lsp.val.town","NODE_ENV","production","CLOUDFLARE_TURNSTILE_SITE_KEY","0x4AAAAAACtaIZJH7s9rBMZ6","GOOGLE_CLIENT_ID","875989696899-jtsqkhlbdv5jrlsk8631p7ipjg3c6o62.apps.googleusercontent.com","STRIPE_PUBLISHABLE_KEY","pk_live_51N2zvWEpZTTLipIkVEwXrUG9AT0yeOOEYxszarZT1jpsZV58Ly6wlg3SltZpHN26CUalOBmUSY7adQRQiSkCZz2500qSXNkf8Y","API_URL","https://api.val.town",[],"preferencesKeybindings","default","preferencesTheme","light","preferencesFixers","preferencesCopilot","preferencesSelectionAi","preferencesCloseBrackets","preferencesChatPanelState","preferencesDprint","preferencesDenofmt","notificationCount","flagDenols","isBusinessOrgMember","businessOrgHandle","isBusinessOrgAdmin","isHigherTownieTier","navCollapsed","currentOrgId"]

Diff · v90