Board Game Arena

Code: Select all

## Summary

On the new table-view page (theme build `260729-1004`), the `<iframe id="gameIframe">` that
hosts a game's content is sized once from a custom property (`--iframeOriginalHeight`) and never
grows to fit content that expands after that initial measurement — including via a maximum-
priority (`!important`, set directly via JS) inline style override on the iframe itself, which
had **zero effect** on its rendered height. That last point is the part I can't explain from the
outside and is why I'm reporting rather than continuing to patch around it: normal CSS cannot
lose to an inline `!important` unless something more structural (CSS containment, or the
element's size being actively re-asserted by your own runtime) is overriding it.

## Environment

- Table: #930692, game `nebuliriumoverlords`, studio.boardgamearena.com
- Theme build: `260729-1004` (matches the day this was found)
- Browser: Safari, macOS

## Reproduction

1. Open a table whose game content is taller than what fits in a typical viewport once BGA's own
   title bar / player panels / active-state banner are accounted for (in our case: item-slot row +
   circular track board + player mats + hand/action area).
2. At a normal/wide browser window size, the game area renders completely blank — not faint, not
   miscolored, just empty space where the board should be.
3. Shrink the browser window until BGA's own responsive layout drops the right-hand log/chat
   sidebar (i.e. crosses into its mobile layout breakpoint) — the game suddenly renders correctly.
4. Widen the window back — it goes blank again. Fully reproducible, deterministic, tied to window
   width / the presence of the sidebar, not to anything transient.

## What we found

Via devtools console, same-origin access into `#gameIframe.contentDocument` (the iframe's `src` is
a same-origin relative path, and its `sandbox` attribute includes `allow-same-origin`):

- The game's own content is correct and fully rendered *inside* the iframe's document — not a bug
  in the game itself. Confirmed via:
  - `#game_play_area`'s own `getBoundingClientRect()`: real width, and a real (non-zero, non-
    origin-clipped) position.
  - `#game_play_area`'s `innerHTML`: fully populated, correctly classed markup (item slots, board
    SVG with 310 real child elements / ~66KB of markup — not an empty shell, not a "Loading…"
    fallback).
  - `getComputedStyle(#game_play_area).backgroundColor`: confirmed correctly applied after we
    added our own fix for an unrelated transparency issue on our side.

- The problem is the **outer `<iframe>` element's own rendered height**, measured from the
  top-level page:
  - `document.getElementById('gameIframe').getBoundingClientRect().height` → **619.13px**
  - `document.getElementById('gameIframe').contentDocument.documentElement.scrollHeight` →
    **2426px**
  - `#game_play_area`'s own rect (inside the iframe) starts at `y: 2038` and is `1176.5px` tall —
    i.e. more than the entire content height needed is past the iframe's own visible bottom edge.
  - The iframe's inline style shows `--autoscaleViewportScale: 1; --autoscaleViewportWidth: 0px;
    --iframeOriginalHeight: 619.125px;` — that height figure matches the rendered height exactly,
    and does not change as the page's actual content grows after load.

- We attempted to correct this from inside the iframe (same-origin, so technically reachable):
  - Setting `window.frameElement.style.height = '2426px'` directly: **no visible effect** on the
    rendered box (still 619.13px).
  - Setting it via `iframe.style.setProperty('height', '2426px', 'important')` — i.e. maximum
    possible priority available to a script, from either side of the frame boundary: **still no
    effect**. Rendered height stayed exactly 619.13px.
  - This second result is the crux of the report: nothing in the normal CSS cascade should be able
    to out-prioritize an inline `!important` declaration. That it did anyway points to something
    more structural — CSS `contain: size` (or similar) on an ancestor decoupling the iframe's
    rendered size from anything set on the element itself, or the height being continuously
    re-asserted by your own app's reactive runtime rather than governed by static CSS at all. We
    don't have visibility into your Svelte source to pin down which.
  - Note: the iframe's class list (`h-full w-full border-0 svelte-tou78d`) does **not** include
    `bga-tableview-frame__iframe--autoscale-viewport`, so the `calc(var(--iframeOriginalHeight) /
    var(--autoscaleViewportScale))` rule tied to that class isn't even the one in play here — we
    checked and ruled that out specifically.

- `--autoscaleViewportWidth: 0px` is present on every table we checked, including a live Hearts
  table that renders fine, so that specific variable is very likely an unrelated default/unused-in-
  this-mode value, not the cause — noting it here only so it doesn't sidetrack anyone digging
  into this the way it initially sidetracked us.

## Ask

Given a game whose content height isn't knowable until after client-side rendering completes
(true for any Studio game using an SPA-style renderer — Svelte/React/Vue — rather than
server-rendered `.view.php`/`.tpl`), is there a supported way to signal a content-height change to
the parent frame so the iframe box can be resized to match? If one exists, pointing us at it would
fully resolve this on our side — we're happy to implement whatever contract you'd want (a
`postMessage` shape, a specific event, etc.). If no such mechanism exists yet, this looks like a
gap in the new iframe-based table view for any game whose page grows after the iframe's initial
load, and reproducing it should be as simple as any Studio game with enough on-page content to
exceed a typical initial viewport height.