Why your game breaks inside an iframe

Everything below was measured on 2 August 2026, in Chrome 150 on Windows, against a real production page rather than a demo: slowden.com/games/hedgies/. Hedgies is a partner game listed on SlowDen, not a SlowDen-made game — we are using the page because it is a normal, live, third-party game embed of exactly the kind your game would land in.

Here is what that page actually is, read out of the live DOM:

Two things in that table are worth sitting with. The host cannot see inside your game at all — which is good for you, and also means the host cannot fix anything on your behalf. And the frame does not have keyboard focus when the page finishes loading.

This is the single most common "it worked yesterday" report, and it is not your bug.

Fullscreen, autoplay, gamepad and friends are Permissions Policy features. Each one has a default allowlist. MDN documents the default for fullscreen plainly: "The default allowlist for fullscreen is self. The top-level browsing context and same-origin iframes are allowed access to the fullscreen feature by default." A cross-origin frame is not in that set. The only way in is the host writing allow="fullscreen" on the <iframe>.

We tested it rather than assuming it. Two frames, identical content, in a cross-origin position; the only difference is the allow attribute:

Notice that gamepad is present in both columns. That is not an accident: MDN gives the default allowlist for gamepad as *, meaning every origin gets it unless a policy takes it away. So gamepad support usually survives an embed; fullscreen and autoplay usually do not. Our measurement and the documented defaults agree exactly, which is a good sign that the test is measuring the real thing.

What to do about it. Do not call requestFullscreen() hopefully and let it reject into a swallowed promise. Read document.fullscreenEnabled at start-up and hide the button when it is false. A missing button reads as a design decision. A button that does nothing reads as a broken game.

There are two separate problems here and they get conflated constantly. They have different causes and different fixes.

Problem one: the sandbox attribute can remove storage completely

If the host wraps you in sandbox without the allow-same-origin token, your document gets an opaque origin — MDN's wording is that the resource is "treated as being from a special origin that always fails the same-origin policy". Origin-keyed storage has no origin to key against, so it does not merely return empty; it throws.

Measured, same content, three different frames:

Be precise about what this does and does not say. Ordinary cross-origin embedding does not produce this error — the live page we measured carries no sandbox attribute at all, and storage is available there. This failure is caused specifically by a sandbox that withholds allow-same-origin. But you do not control which hosts do that, so you have to survive it.

What to do about it. Never let a bare localStorage call sit in your load path. Probe once at boot, inside try/catch, and fall back to an in-memory object that satisfies the same interface. Your game then runs to completion with saving quietly disabled, instead of dying on line one with a red error nobody will report to you.

// Run this once, before anything else touches storage.
let store;
try {
  localStorage.setItem('__probe', '1');
  localStorage.removeItem('__probe');
  store = localStorage;
} catch (e) {
  const mem = new Map();
  store = {
    getItem: k => (mem.has(k) ? mem.get(k) : null),
    setItem: (k, v) => mem.set(k, String(v)),
    removeItem: k => mem.delete(k)
  };
  // Optional: hide your "save" UI here rather than letting it lie.
}

Problem two: storage is partitioned, so saves do not travel

Suppose storage works fine. Your player has a save on your own site. They find the same game on a portal, load it, and the save is not there. Nothing is broken.

Chrome partitions storage in third-party contexts. Google's own documentation states that the feature "has been enabled for all users on Chrome 115 and later", and that the partition key combines the origin of the embedded context with the top-level site doing the embedding. LocalStorage, sessionStorage, IndexedDB and Cache Storage are all covered.

The practical consequence for a game developer is blunt:

• Your game on your domain, on portal A, and on portal B has three separate save files.
• Clearing one does not clear the others. Testing one tells you nothing about the others.
• Local storage cannot be an account system. If progress genuinely needs to follow a person, it needs a server and a login, and that is a much bigger decision than it looks from inside a jam build.

What to do about it. Design saves as a convenience, not a contract. Never write UI copy that promises a player their progress is safe or will be there next time, because on somebody else's page you cannot honour it.

People lose hours to this one, usually chasing a decoding bug that does not exist.

Browsers will not let a page make noise before the person has interacted with it. An AudioContext created while the page is loading comes up suspended and stays silent until something resumes it inside a real input event. We measured state: "suspended" on a freshly loaded page with no interaction — both at the top level and inside the frame, which is the point: this is not an iframe problem, it is a page-load problem that the iframe then makes harder to notice.

Then the frame adds a second lock on top. Autoplay is a Permissions Policy feature and MDN gives its default allowlist as self — the same rule as fullscreen. So a cross-origin frame needs allow="autoplay" from the host before it may make sound even after a gesture.

What to do about it. One fix covers both: never start audio at boot. Create the context lazily, or create it early and call resume() inside the handler for the first real click, tap or key press. If you already have a start button, you already have the gesture — just make sure the resume happens in that handler and not in a promise chain three ticks later, because the gesture does not last forever.

On the live page we measured, document.activeElement was BODY after load. The frame only became the active element once focus was explicitly given to it — at which point activeElement reported IFRAME.

That gap is where a whole class of "the controls don't work" reports comes from. Until the frame has focus, key events belong to the host document. Your window.addEventListener('keydown', ...) is bound correctly and receives nothing, while the player's arrow keys and spacebar scroll the portal's page around them.

What to do about it. Put a click-to-start overlay inside your game and do not begin play until it is dismissed. It is the single highest-value 20 lines in a portal build, because that one click does three jobs at once:

• It gives the frame focus, so the keyboard starts working.
• It is the user gesture that lets audio resume.
• It gives you a defined moment to start heavy loading, instead of hammering the host page's bandwidth the instant it renders.

While you are there: call preventDefault() on the keys you use. Space and the arrow keys scroll by default, and a game that scrolls the page under itself feels broken even when it is working.

The last one is not a permission at all, it is geometry, and it is the one most likely to be silently costing you players.

On the live page, in a browser window 730 px tall, the game frame was 1054 × 658 px and began at y = 251, because a header, a breadcrumb trail and a title sit above it. That leaves 479 px of the game visible — 73%. The bottom quarter of your game is below the fold before the player has scrolled anything.

Now imagine what lives in that bottom quarter in most jam builds: the start button, the mute toggle, the controls legend, the "click here to begin" text.

What to do about it.

• Keep anything the player must find in the upper-middle of your canvas. Treat the bottom strip as decoration.
• Scale to the frame you are given, not to a fixed 1920×1080. Read your container size and lay out from it.
• Test at an awkward aspect ratio on purpose. A tall thin frame and a short wide frame will both happen to you.
• Do not rely on fullscreen to rescue the layout — see section 1, you may not get it.

You do not need a portal to find these problems. Open any page in your browser, open the console, and paste this. It embeds a probe in a cross-origin position and reports what that position allows. It is the same script that produced the numbers above.

const child = `<script>
  var r = {};
  try { r.fullscreen = document.fullscreenEnabled; } catch(e) { r.fullscreen = 'THREW'; }
  try { r.origin = String(window.origin); } catch(e) { r.origin = e.name; }
  try { localStorage.setItem('t','1'); r.storage = 'OK'; localStorage.removeItem('t'); }
  catch(e) { r.storage = e.name; }
  try { var AC = window.AudioContext || window.webkitAudioContext;
        var ac = new AC(); r.audio = ac.state; ac.close(); } catch(e) { r.audio = e.name; }
  try { r.features = document.featurePolicy.allowedFeatures()
        .filter(function(f){ return ['fullscreen','autoplay','gamepad','clipboard-write']
        .indexOf(f) > -1; }); } catch(e) { r.features = 'unavailable'; }
  parent.postMessage(JSON.stringify(r), '*');
<\/script>`;

function probe(allowAttr) {
  return new Promise(res => {
    const f = document.createElement('iframe');
    f.setAttribute('sandbox', 'allow-scripts');   // forces a cross-origin position
    if (allowAttr) f.setAttribute('allow', allowAttr);
    f.style.cssText = 'position:absolute;left:-9999px;width:1px;height:1px';
    const h = e => { try { const d = JSON.parse(e.data);
      window.removeEventListener('message', h); f.remove(); res(d); } catch(_) {} };
    window.addEventListener('message', h);
    f.srcdoc = child;
    document.body.appendChild(f);
  });
}

console.log('no allow=  ', await probe(null));
console.log('with allow=', await probe('autoplay; fullscreen; gamepad; clipboard-write'));

Then run the same four checks inside your actual game at start-up and log them. If fullscreenEnabled is false, hide the button. If storage throws, switch to the in-memory fallback. If audio is suspended, wait for the click. Four checks, four graceful degradations, and your game stops depending on a hospitable host.

So you can check them rather than take our word for it. All measured on 2 August 2026 in Chrome 150 on Windows:

• The live embed's attributes, origins and focus state were read from the DOM of slowden.com/games/hedgies/ in a real browser. Hedgies is a partner game listed on SlowDen, made by a third-party studio — SlowDen did not make it, and most games listed on SlowDen are partner or third-party titles rather than SlowDen's own work.
• The Permissions Policy and storage results came from the probe script printed above, run twice with the only variable being the allow attribute, and a second time with the only variable being the sandbox attribute.
• The frame geometry came from getBoundingClientRect() on the live page at the default scroll position, in a window with an inner height of 730 px. Your numbers will differ with window size — the ratio is the point, not the pixel count.
• The documented defaults are MDN's Permissions Policy directive pages for fullscreen, autoplay and gamepad, and MDN's <iframe> reference for the sandbox and allow-same-origin behaviour.
• Storage partitioning is Google's Privacy Sandbox documentation on storage partitioning, which states the feature is enabled for all users on Chrome 115 and later.
• Browser scope: everything here was measured in Chrome only. The Permissions Policy defaults are standardised, but do not assume the exact same behaviour in Safari or Firefox without testing — treat this as a starting checklist, not a cross-browser matrix.

Every one of these failures shares a shape. The game is fine. The host is fine. Nobody did anything wrong. But the player clicks, gets silence and a dead button, and leaves — and you never hear about it, because people who bounce do not file bug reports.

The good news is that all six fixes are small, they are all defensive, and none of them costs you anything when the host is generous. A game that checks four flags at start-up and degrades quietly will run everywhere you put it. That is worth more than another feature.

If you have a browser game that has never been embedded anywhere, this is a reason to try it rather than a reason not to. Submitting it to SlowDen is free and takes a link. And if you would rather build something new for the occasion, the current Slow Cook round closes on 31 August 2026 — pick a prompt, build a small complete game, and submit it for a chance to be featured. Selected entries may receive a shoutout on SlowDen's social accounts; nothing is guaranteed, and every entry is reviewed by a person.

• Why your browser game loads to a black screen — the other half of this problem: what happens before your first frame ever renders.
• Which browser-game portals actually have players on them — how to tell a host from an audience before you spend a week on a listing.
• Where to publish your HTML5 game free in 2026 — the places worth trying, and what each one expects from your build.
• How to submit your browser game to SlowDen — what to prepare, and what you can honestly expect.