diff --git a/.fallowrc.jsonc b/.fallowrc.jsonc index fd1cc03ffe..0fcb2140f9 100644 --- a/.fallowrc.jsonc +++ b/.fallowrc.jsonc @@ -544,6 +544,12 @@ // this PR only teaches the server scan to prefer its reported PID, but that // line shift makes fallow re-flag the inherited probe clones. "packages/cli/src/server/portUtils.ts", + // iframe.test.ts: the remaining clone groups are pre-existing per-case arrange + // blocks in the selection and draft-loop suites (build an adapter, wire a spy, + // act). Appending the paint-query suite shifts their line numbers and re-flags + // them; each block states its own setup on purpose, which a shared fixture + // would hide. + "packages/sdk/src/adapters/iframe.test.ts", // gsapParserAcorn.motionEval.test.ts: parallel arrange/act/assert cases for // the staggered-collection honesty pass (.from reveal vs .to landing on the // rest pose). Each asserts a distinct keyframe shape; collapsing the shared diff --git a/docs/sdk/guides/canvas-integration.mdx b/docs/sdk/guides/canvas-integration.mdx index 80b17a9836..87fbb37921 100644 --- a/docs/sdk/guides/canvas-integration.mdx +++ b/docs/sdk/guides/canvas-integration.mdx @@ -99,6 +99,65 @@ iframeDoc.addEventListener("click", (e) => { `resolveNearestHfElement` returns `null` when the walk exits the tree without finding a `[data-hf-id]` node, when the matching node carries `[data-hf-root]` (the root is transparent to selection), or when `isVisible` returns `false` for that node. +## Transparent compositions over other content + +A composition authored as an overlay — a small graphic on an otherwise-empty 1080×1920 frame, layered over a video or an avatar — is still a rectangular DOM box covering every pixel of the frame. Without help it swallows every click, and whatever sits beneath it becomes unreachable. + +`preview.isProvablyEmptyAt(x, y)` is the question you need answered: is this point provably free of ink, so a click may safely reach what sits beneath? Toggle `pointer-events` on your wrapper from the answer, and let the browser deliver the event to the right target: + +```typescript +const wrapper = document.querySelector("#composition-wrapper")!; + +/** + * Host-page pointer coordinates → the iframe document's own client space, which is what + * the paint query samples against. The iframe renders at the composition's native size and is + * CSS-scaled to fit, so the on-screen scale has to be divided out — skip this and you + * sample the wrong pixel, and pass-through toggles over the wrong regions. + */ +function toCompositionPoint(clientX: number, clientY: number) { + const rect = iframe.getBoundingClientRect(); + if (!rect.width || !rect.height) return null; + const scaleX = rect.width / compositionNativeWidth; + const scaleY = rect.height / compositionNativeHeight; + if (!scaleX || !scaleY) return null; + return { x: (clientX - rect.left) / scaleX, y: (clientY - rect.top) / scaleY }; +} + +function updatePassThrough(clientX: number, clientY: number, altKey: boolean) { + const point = toCompositionPoint(clientX, clientY); + // Alt is the escape hatch for grabbing the composition itself in an empty region. + // Every uncertain case — no point, still loading, adapter without the method — is + // falsy here, so the composition stays clickable rather than vanishing. + const passThrough = + !!point && !altKey && !!preview.isProvablyEmptyAt?.(point.x, point.y); + wrapper.style.pointerEvents = passThrough ? "none" : ""; +} +``` + + + Listen on the **host document**, not on the wrapper or the iframe. The first time this + sets `pointer-events: none` the wrapper stops receiving events, so a listener attached + there can never turn it back on — the pass-through state sticks. + + +Three things are easy to get wrong here: + + + + The browser picks an event's target before any handler runs, so flipping `pointer-events` inside `mousedown` cannot retarget the click already in flight. Sample the pointer position on `mousemove` and keep the decision current. + + + Animated artwork moves under a stationary cursor. Anything that can change the answer — pointer movement, the Alt key, and the playhead — has to re-run the query from the last known position. Coalesce those triggers into one `requestAnimationFrame` query rather than answering each separately, and short-circuit before the query when the pointer is outside the composition's box: it is a walk over the document, so it does not belong on an ungated per-event path. + + + `isProvablyEmptyAt` is true only when it has established there is no ink. A document that hasn't loaded, an adapter without the method, and a point you couldn't map all come back falsy — which keeps the composition clickable. Don't invert it into a "does it paint" variable; that reintroduces the bug the polarity removes. + + + +Pass `{ fullBleedFraction: 0.9 }` if your editor treats a layer covering nearly the whole frame as background rather than artwork — a common choice, since a full-bleed wrapper is usually scaffolding rather than something the user is pointing at. + +Do not reimplement this with `elementsFromPoint`. That stack omits `pointer-events: none` nodes, and a decorative overlay carrying `pointer-events: none` still paints — a z-stack query would report no ink over visible artwork and pass the click through anyway. The paint walk covers element boxes geometrically for that reason. + ## Draft loop: 60fps drag without model mutations The draft loop keeps the model clean during a drag. The SDK is **not** in the 60fps path — you call `preview.applyDraft` on every `pointermove` and `preview.commitPreview` once on `pointerup`. The model sees exactly one `moveElement` op per drag, rather than hundreds. diff --git a/docs/sdk/reference/adapters.mdx b/docs/sdk/reference/adapters.mdx index a8b6a6760a..93b962243e 100644 --- a/docs/sdk/reference/adapters.mdx +++ b/docs/sdk/reference/adapters.mdx @@ -87,6 +87,7 @@ Injectable preview surface adapter. Decouples the SDK from the host's rendering ```typescript interface PreviewAdapter { elementAtPoint(x: number, y: number, opts?: { atTime?: number }): ElementAtPointResult | null; + isProvablyEmptyAt?(x: number, y: number, opts?: PaintQueryOptions): boolean; applyDraft(id: string, props: DraftProps): void; commitPreview(): void; cancelPreview(): void; @@ -100,6 +101,24 @@ interface PreviewAdapter { Synchronous hit-test at composition coordinates `(x, y)`. Returns the nearest `[data-hf-id]` element under the point, or `null` for a transparent hit (the composition root, an opacity-0 element, or nothing at all). Requires a same-origin iframe — cross-origin access throws a DOMException. The `atTime` option reflects GSAP state at the current playhead; seeking to a speculative time is not supported. + + Optional. Is `(x, y)` provably free of ink — is it safe to let a click pass through to whatever sits beneath? This is the question a host has to answer before a transparent composition layered over other content swallows a click: is the user pointing **at** artwork, or through an empty gap? Geometry alone cannot tell — a composition is mostly full-bleed wrapper `
`s that cover every pixel of the frame without painting anything. + + **True only when the composition was readable and nothing painted there.** Ink present, a document still loading or unreadable, and an adapter that doesn't implement the method (`preview.isProvablyEmptyAt?.(x, y)` → `undefined` → falsy) all come back falsy. That polarity is deliberate: it puts the burden of proof on passing the click through, so every way of failing keeps the composition clickable rather than making it vanish from under the cursor. The obvious call site is safe by construction: + + ```typescript + if (preview.isProvablyEmptyAt?.(x, y)) passThrough(); + ``` + + Ink is a computed-style test — background colour, background image, visible border, the element's own text, or intrinsic media — with one exception: `` (and the `` inside a ``) routes through per-pixel alpha, so a transparent PNG paints only where its pixels do. A pixel-verified hit is never discounted by `fullBleedFraction`: box area is not ink area, so a full-frame transparent overlay stays clickable where it is actually opaque. + + **Known over-counts** (report ink that isn't there, so a click selects the composition): a `background-image` that is itself mostly transparent reads as painting across its whole box; `