Repository navigation
Description
Summary
Studio's live thumbnail-generation endpoint (GET /api/projects/:project/thumbnail/:path?t=...) renders styleframe/composition HTML with a broken dark background and illegible (near-invisible) text, even though the same HTML renders correctly when captured directly with the same headless Chrome binary the CLI vendors (bypassing this specific endpoint). This makes the Storyboard/Board view unusable for reviewing designs on any project once it reaches a certain scale.
What's ruled out
- Not a hyperframes version issue — reproduces identically on 0.7.76, 0.7.87, and the latest 0.7.89.
- Not GPU/rendering-related — reproduces with both default (auto) GPU and
--no-browser-gpu(SwiftShader). - Not caching — reproduces on a freshly-started server, on a brand-new port, with
.thumbnailscache cleared. - Not CSS-content-specific — a page using only inline
<style>, or an external stylesheet with CSS custom properties andcolor-scheme: light only, renders correctly through this same endpoint in a small project. - It is scale-triggered, not content-triggered. The exact same trivial HTML (plain white/lavender gradient background, one text element) renders correctly via this endpoint in a project with 1-2 sibling files, and renders with the broken dark background in a project with ~21+ sibling files in the same directory — with zero difference in the file's own content or CSS.
Reproduction (fully generic, no project-specific content)
- Create a project directory:
hyperframes.json: {"$schema": "https://hyperframes.heygen.com/schema/hyperframes.json"} index.html: (minimal valid composition scaffold, 1920x1080, empty #root) design/styleframes/_shared.css: :root { --ink:#18181b; --lav2:#dad0ff; } * { margin:0; padding:0; box-sizing:border-box; } html, body { width:1920px; height:1080px; overflow:hidden; } body { font-family: system-ui, sans-serif; color: var(--ink); } .stage { position:absolute; inset:0; background: linear-gradient(#ffffff 0%, #ffffff 52%, var(--lav2) 100%); } .txt { position:absolute; left:96px; top:140px; font-size:56px; font-weight:700; } - Create 21 near-identical sibling files
design/styleframes/frame-01.html…frame-21.html, each:<!doctype html> <html lang="en"> <head><meta charset="UTF-8" /><title>Frame N</title> <link rel="stylesheet" href="_shared.css" /> </head> <body><div class="stage"><div class="txt">Frame N placeholder content</div></div></body> </html>
npx hyperframes preview --port 3196 --no-opencurl "http://localhost:3196/api/projects/<project>/thumbnail/design/styleframes/frame-01.html?t=0.00" -o thumb.png- Open
thumb.png— expected: white-to-lavender gradient background, dark readable text. Actual: dark navy background (~#1a1d29-ish), same dark text now illegible against it. - For comparison, capture the same file directly (not through the endpoint) with the CLI's own vendored
chrome-headless-shell --headless --screenshot=direct.png --window-size=1920,1080 file://.../frame-01.html— renders correctly. - Repeat with only 1-2 sibling files instead of 21 — renders correctly through the Studio endpoint too. The sibling-file count in the same directory appears to be what flips the behavior.
Impact
This affects the Board/Storyboard review view for any real (non-trivial) HyperFrames project — the exact surface meant to let a human review a design/storyboard before build. On a real production project it made every single frame thumbnail illegible, which is a significant workflow blocker since it's the primary human review surface for that pipeline stage.
Environment
- macOS, Apple Silicon (M1 Pro)
- hyperframes 0.7.76 / 0.7.87 / 0.7.89 (all reproduce)
- Chrome-headless-shell vendored by the CLI, ANGLE Metal renderer
Activity
fix(studio): resolve sibling asset paths in sub-composition previews (#…