Canvas recording enabled, but rrweb emits zero canvas mutations (posthog-js 1.428.6)

[artur-hakobyan]

Bug Description

Project 268554 (EU Cloud), posthog-js 1.428.6, site: hookscreener.com

"Capture canvas elements" is ON and the remote config confirms it in the page:
{"recordCanvas": true, "canvasFps": 3, "canvasQuality": "0.4",
"recorderVersion": "v2", "scriptConfig": {"script": "posthog-recorder"}}

But every replay shows canvas areas blank.

Running rrweb directly on the page with recordCanvas:true gives ZERO canvas
mutations (type:3, source:9) while DOM mutations are captured normally:

{ total: 48, canvas: 0, bySource: { "0": 18 } }

At the same time the canvases are in the DOM, visible, and non-empty —
toDataURL("image/webp",0.4) returns 15,000–27,000 bytes for each of 11
.bkv__canvas elements.

CONTROL TEST: a brand-new plain 2D canvas, appended to the DOM and drawn to
40 times WHILE recording was running, also produced zero canvas events:

{ total: 34, canvasEvents: 0 }

So this is not specific to our rendering.

Already ruled out: SDK version (1.428.6 >> 1.105.7), project setting, a stale
config cache on our proxy (now no-store, verified), WebGL (we use 2d only),
recording being off (DOM events arrive, "[SessionRecording] starting" logs).

Is this PR PostHog/posthog#93133 ("apply later attribute mutations to the canvas replacement
image")? Its description matches our symptom exactly — "content can stay
invisible for a whole replay, even though the pixels were captured". Our
canvases do mutate width/height after creation on resize/zoom.

If so, is there an ETA for EU Cloud? Note PostHog/posthog#93133 explains blank PLAYBACK but
not the control test above, where no canvas events were emitted at RECORDING
time — possibly two separate issues.

Debug info

- [ ] PostHog Cloud, region and project ID: [please provide, you can find both at https://app.posthog.com/settings/project-details#variables]
- [ ] PostHog Hobby self-hosted with `docker compose`, version/commit: [please provide]
- [ ] PostHog self-hosted with Kubernetes (deprecated, see [`Sunsetting Kubernetes support`](https://posthog.com/blog/sunsetting-helm-support-posthog)), version/commit: [please provide]

[github-actions]

AI triage for #4968

Conclusion: Likely a canvas FPS capture compatibility/failure-path issue, distinct from a playback-only canvas replacement fix.
Confidence: 87%
Suggested labels: feature/replay, javascript

Thanks for the detailed isolation work. The absence of type: 3, source: 9 events is a recording-side problem, so it would be separate from a change that only fixes applying already-recorded canvas pixels during playback.

There is a relevant implementation detail: the remote canvasFps: 3 setting makes posthog-js use rrweb's sampled-frame canvas path rather than the per-2D-call observer. That path requires OffscreenCanvas and an inline worker; it intentionally emits no frames when OffscreenCanvas is unavailable, and it can also stop without affecting DOM recording if the worker cannot load. The repository also currently skips its browser test for this path in headless WebKit because it emits no canvas mutations there despite the relevant primitives being present.

Could you provide:

1. The browser name and exact version for an affected recording (and whether it is Safari/WebKit or an in-app webview).
2. The exact direct rrweb record(...) invocation, especially its sampling.canvas value, plus a minimal standalone HTML reproduction if possible.
3. Output of typeof OffscreenCanvas, typeof createImageBitmap, and typeof Worker on the affected page.
4. Any console CSP/worker errors involving blob: URLs or the recorder worker, and the page's worker-src / script-src CSP directives.
5. Whether the full snapshot contains rr_dataURL on the canvas nodes. Counting source-9 events alone does not show whether the initial canvas still was captured.

We should reproduce this in the reported browser before proposing a fallback or changing the capture path: such a change affects recorder performance, recording volume, and canvas-pixel handling across all customers. There is no ETA determination possible from this SDK repository alone.

Investigation

• The SDK converts enabled remote canvas configuration into recordCanvas: true and sampling.canvas: canvasFps; the reported canvasFps: 3 therefore selects rrweb's numeric FPS snapshot path.
• The numeric FPS path returns immediately, with no canvas mutation observer or frame loop, when OffscreenCanvas is absent. rrweb's public type documentation explicitly says numeric canvas sampling is supported only where OffscreenCanvas is supported.
• The same FPS path creates an inline encoding worker and silently disables canvas snapshotting if worker construction fails or its error handler fires. DOM recording is independent of this path.
• The browser Playwright canvas-resolution test documents a pre-existing case where the FPS pipeline produces no canvas mutations under headless WebKit even though OffscreenCanvas, image-bitmap operations, and the worker are present; the test is skipped there.
• The repository changelog records an intentional behavior change to skip FPS canvas recording on browsers without OffscreenCanvas support, specifically Safari before 16.4.
• Initial full snapshots can serialize a nonblank 2D canvas as rr_dataURL; source-9 incremental events are not the only possible recorded canvas pixels.
• The direct rrweb control is not yet independently reproducible from the issue because its complete options, browser, timing, and CSP are absent. If it used numeric sampling, it exercises the same FPS path; if it truly used default sampling, it should instead exercise the 2D method-patching observer.

Relevant files: packages/browser/src/extensions/replay/external/lazy-loaded-session-recorder.ts, packages/rrweb/rrweb/src/record/observers/canvas/canvas-manager.ts, packages/rrweb/rrweb/src/record/observers/canvas/2d.ts, packages/rrweb/rrweb-snapshot/src/snapshot.ts, packages/rrweb/types/src/index.ts, packages/browser/playwright/mocked/session-recording/canvas-resolution.spec.ts, packages/browser/CHANGELOG.md, .agents/skills/replay-incident-risk/INCIDENTS.md

Fix assessment

• Straightforward: no
• Risk: high
• Reason: A safe fix depends on distinguishing unsupported WebKit behavior, a blocked/failed inline worker, and a regression in the default per-call observer. A fallback between capture modes would change fleet-wide replay CPU, payload volume, and canvas-pixel capture behavior, so it needs a real-browser reproduction and regression test first.

Pi session

The resumable JSONL pi session for this run was saved to a private gist: https://gist.github.com/marandaneto/fb676c1d6209952357cb9f44efa4dada

Download it locally, then fork it into your own pi session:

pi --fork path/to/session.jsonl

Saved session:

• call-1-1-2026-09-15T12-37-10-224Z_01a0a512-39d0-7221-9b64-f9148bbb4411.jsonl

Close proposal

None. No issue close action was taken.

---

Generated by posthog-watcher-action using pi.