[miguel-heygen]

What

Two scenes in one composition can now draw their SVGs with the same ids. Each scene's url(#id) and href="#id" resolve to its own definitions in preview, snapshot and render.

Why

A report: snapshot --at 4,86,141 on a film with two distinct inline SVG character portraits, one per scene, showed the first portrait again in the last scene.

Both portraits were written straight into index.html, one per scene clip, and both used the same ids (a gradient, a clip path, a symbol). The browser resolves url(#skin) and href="#portrait" to the first element with that id in the page, so the second scene painted the first scene's pieces, and its own gradient painted nothing while the first scene was hidden. Render shows the same thing as snapshot. The same portraits as two sub-compositions (data-composition-src) come out right, because loading a sub-composition renames colliding SVG ids; ids written in the main page were never renamed.

Related work

None.

How

svgIdNamespacing.ts already renames colliding SVG ids per scope (each inlined composition), keeps the first definition's id, and rewrites only that scope's references. The new sceneClipRoots adds one more kind of scope: each outermost timed clip (data-start) that holds an <svg>, outside every composition host. The compiler (inlineSubCompositions) and the runtime loader (namespaceMountedSvgIds) both pass those clips to the same renamer, next to the composition hosts.

What it leaves alone:

• Ids that don't collide: they keep their names, as before.
• Definitions at page level, outside every clip: they are never renamed, and a clip that references one without defining its own still resolves to it.
• The first scene: the first definition keeps its id; only later clips' copies are renamed (clip-1--skin) and their own references follow.

Test plan

• inlineSubCompositions.test.ts "gives each scene clip its own portrait when two scenes reuse the same SVG ids": each scene's fill and href resolve inside that scene, and the first scene keeps its ids. "leaves a page-level definition the scenes share where it is": both scenes still use url(#shared).

• compositionLoader.test.ts "resolves each top-level scene clip to its own clipPath, and a shared page-level one for both": the same at runtime.

• snapshot.sceneSvgIds.browser.test.ts: two red/blue portraits with the same ids, plus a corner filled from a page-level gradient, snapshotted at 4 s and 14 s, reading pixels.

• fails without the fix: with main's three source files, the compiler test, the loader test and the snapshot test fail (at 14 s the face is black and the corner piece red); the page-level test passes either way, as a guard.

• Before and after, over every registry example, block and component and every producer regression project (549 entries):

  • Compile: each compiles to byte-identical HTML with and without this change. With no sub-compositions the compiler has nothing to inline, so for top-level scenes the change acts in the runtime loader.
  • Runtime: the loader renames only an id that a scene clip defines, references, and that is defined elsewhere too. A census of every compiled page found 24 scene clips holding an SVG and no such id in any of them. Ten producer projects with video fixtures did not compile in that run, and none of them contains an <svg>. The census does flag the repro fixture, so it can see the case it looks for.

• Unit tests added/updated

• Manual testing performed

• Documentation updated (if applicable)

• Comments follow CONTRIBUTING.md "Comments": they say why, not what, and a bug fix says what the code must do and how to reproduce the bug

Not exercised: the reporter's own project, and full renders of the regression projects; the census above is why none of them can change.

[github-actions]

Edit accuracy: accurate 267 (base branch 267), smooth 103 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): fail / pass / 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 (2)

• seqrepeat-none-center-r0-root-z100: tracking 0.05, pressJump 0, drop 0, reload 0, render 0.02, renderKey -, undo true, teleport true / tracking 0.05, pressJump 0, drop 0, reload 0, render 0.02, renderKey -, undo true, teleport true / tracking 0.05, pressJump 0, drop 0, reload 0, render 0.02, renderKey -, undo true, teleport true
• seqplainkeys-none-pct-r0-nested-z100: tracking 0.05, pressJump 0, drop 0, reload 0, render 0.02, renderKey -, undo false, teleport true / tracking 0.05, pressJump 0, drop 0, reload 0, render 0.02, renderKey -, undo true, teleport true / tracking 0.05, pressJump 0, drop 0, reload 0, render 0.02, renderKey -, undo true, teleport true

[heygengenesis]

Verdict: REQUEST CHANGES · 1 blocker · 0 important · 0 nits · head bfe2db3c

The fix itself looks right, and both named unit tests fail on main's source files when I run them. The blocker is that required CI is red: Typecheck and Test: runtime contract both fail with TS2339 at compositionLoader.ts:917 (↓ inline). It's a one-line type annotation.

Scope

Read all 6 files plus the namespaceCollidingSvgIds / selector-alias paths they feed. Ran inlineSubCompositions.test.ts and compositionLoader.test.ts locally (116/116 pass). With main's three source files restored, the two new scene tests fail and the page-level guard passes, which matches the fails without the fix: line. I checked that the annotation below clears the TS error locally. I didn't run the browser snapshot test locally; the CLI test shards pass in CI. Out of scope: scenes that sit inside a timed wrapper clip, and <svg data-start> used directly as the clip. Both stay in one scope, which is no regression.

[heygengenesis]

blocker: TypeScript infers mounted as the union MountedSvgScope | { host; namespace; styles: never[] }, so destructuring referenceTarget at L917 fails typecheck: TS2339: Property 'referenceTarget' does not exist. That error fails CI jobs Typecheck and Test: runtime contract.

Suggested change

	const mounted = [
	const mounted: MountedSvgScope[] = [

[heygengenesis]

✅ Fixed in 063292b

[heygengenesis]

Verdict: APPROVE — 1 resolved, 0 open, 0 new · bfe2db3 → 063292b. The only change since bfe2db3 is the suggested MountedSvgScope[] annotation, and Typecheck and Test: runtime contract now pass.