[miguel-heygen]

What

Fast (drawElement) capture now marks its canvas the way the running Chrome asks for: layoutsubtree on Chrome up to 156, content="drawable" plus drawable on the composition root on 157+. The single-worker pin for html-in-canvas compositions also recognises the 157 canvas.

Why

Chrome 157 became Stable and renamed the opt-in. The engine's wrapper canvas always set layoutsubtree, so on a 157 browser every fast-capture export died at the first frame with InvalidStateError: Failed to execute 'drawElementImage' on 'CanvasRenderingContext2D': DrawElementImage requires the canvas to have the content=drawable attribute.

fails without the fix: drawElementCanvasForm.browser.test.ts (both cases, against a real Chrome 157.0.8103.78 and against Chrome 152 with its 157 marks simulated) and the new htmlCompiler.test.ts case.

Related work

packages/core/src/htmlInCanvas.ts already owns the form decision for authored canvases (htmlInCanvasForm); the engine was the one capture path still hardcoding the old form. No open PR touches this.

How

• injectDrawElementCanvas asks the page for htmlInCanvasForm() (the same function core uses) and applies the matching marks. A build with drawElementImage but no requestPaint keeps layoutsubtree, as before.
• detectRenderModeHints uses core's CAPTURE_CANVAS_SELECTOR instead of its own canvas[layoutsubtree], so a composition authored with the 157 canvas is still pinned to one worker.

Test plan

• Unit tests added/updated
• Manual testing performed
• Documentation updated (if applicable)
• Comments follow CONTRIBUTING.md "Comments"

What I measured

On a Linux box, headless shell, --enable-features=CanvasDrawElement:

• Chrome 157.0.8103.78: layoutSubtree is absent from the canvas, updateElementGeometry present; a layoutsubtree canvas throws the error above; content="drawable" plus drawable on the child is accepted.
• Chrome 152.0.7977.30 (the pinned build): layoutsubtree accepted, content="drawable" refused.
• New browser test, 3 runs in a row on each of 152 and 157: 2 passed, 0 skipped, exit 0. With drawElementService.ts reverted to main: 152 run 1 failed / 1 passed, 157 run 2 failed.
• drawElementService.test.ts: 22 passed. htmlCompiler.test.ts: 179 passed; with htmlCompiler.ts reverted, the new case fails (178 pass, 1 fail).

What I did NOT execute

• A full export on Chrome 157 or on Windows: only the canvas injection and the draw call were exercised.
• The full engine and producer suites (CI runs them).
• packages/shader-transitions still probes for layoutSubtree, so on 157 its page-side compositor and html-in-canvas scene capture report unsupported and use their existing fallbacks; unchanged here.

Size

About 120 changed lines, of which about 90 are the new browser test; the fix itself is about 15 lines in two files.

[github-actions]

Edit accuracy: accurate 267 (base branch 267), smooth 88 of those

The gate passes.
Smoothness is reported in the artifact, not gated. A case fails only if it fails 2 of 3 runs.

Quarantined, measured but not gated (8)

• seqplainkeys-none-center-r0-nested-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): pass, passes
• seqplainkeys-none-center-r0-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): pass, passes
• seqplainkeys-none-center-r30-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): not run
• seqplainkeys-none-pct-r0-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): pass, passes
• seqplainkeys-none-pct-r30-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): not run
• seqplainkeys-none-px-r0-nested-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): pass, passes
• seqplainkeys-none-px-r30-nested-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): not run
• seqplainkeys-none-px-r30-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): not run

Unstable (1)

• seqplainkeys-none-px-r0-root-z100: tracking 0.06, pressJump 0, drop 0, reload 0, render 0.03, renderKey -, undo false, teleport true / tracking 0.06, pressJump 0, drop 0, reload 0, render 0.03, renderKey -, undo true, teleport true / tracking 0.06, pressJump 0, drop 0, reload 0, render 0.03, renderKey -, undo true, teleport true

[heygengenesis]

Verdict: APPROVE · 0 blocker · 0 important · 0 nits · head f45ddb97

The fix uses core's htmlInCanvasForm/CAPTURE_CANVAS_SELECTOR, so the engine and producer now follow the same Chrome-version decision as authored canvases.

Scope

Read the full diff. Rule-2 sweep: every engine drawElementImage call draws root inside __hf_de_canvas, which injectDrawElementCanvas marks. The remaining engine layoutsubtree mentions (frameCapture.ts:1296, threeDProjection.ts:9) are comments. shader-transitions still probes layoutSubtree; the PR discloses this and it uses the existing fallback. The "fails without the fix:" line names drawElementCanvasForm.browser.test.ts and the new htmlCompiler.test.ts case. CI ran the browser test (2 passed; flake gate 10/10). All Actions runs pass at this head, including Windows render verification. Not exercised by anyone: a full export on a real Chrome 157.