inlineImages encodes at full natural resolution, with no way to cap it

[michal-baya]

Affected: rrweb-snapshot 2.0.1, serializeElementNode, the img branch.
Same code in the copy bundled by rrweb 2.0.0-alpha.17 — anchors below are from
that bundle (dist/rrweb.js), where I could read them directly.

What the code does (dist/rrweb.js:897 onwards):

canvasService.width  = image.naturalWidth;
canvasService.height = image.naturalHeight;
canvasCtx.drawImage(image, 0, 0);
attributes.rr_dataURL = canvasService.toDataURL(
  dataURLOptions.type,
  dataURLOptions.quality
);

The canvas is sized to the image's natural dimensions with no cap, and
toDataURL runs on the main thread. When dataURLOptions is unset both
arguments are undefined, so the browser encodes a lossless PNG.

For a 2560x1920 source (4.9 Mpx) that is a large encode. I want to be explicit
that I have not measured the resulting byte count on our own corpus — the
figures usually quoted for lossless PNG at that pixel count are in the
single-digit MB range before base64, but treat that as an order-of-magnitude
expectation, not a measurement. What I did measure is the effect: our ingest
endpoint, which accepts 10 MiB of decompressed JSON, answered 413 on these
payloads.

Why this matters beyond size. The encode is synchronous, so on a page that
brings several full-resolution images into the DOM at once it can block the
main thread for a user-visible stretch. In our incident the gallery had already
painted before the encoding ran, because the work is deferred to each image's
load handler — note this is incident-specific, not guaranteed by the code:
when image.complete is already true the branch encodes immediately instead
(dist/rrweb.js:932).

Why the existing option is not enough. Within serializeElementNode's
img/canvas paths, dataURLOptions reaches only toDataURL(type, quality). It
never influences canvas sizing. Switching to image/webp q0.8 cuts the payload
by a large factor and, together with a byte budget on our side, resolved the
413. It does not remove the synchronous encode of a 4.9 Mpx canvas, so the
main-thread cost remains.

I could not find a public lever for this: recordOptions, plugins,
hooks.mutation, packFn and eventProcessor all act on the finished payload
(mutationCb at :11113, hooks.mutation wrapping it at :12259,
eventProcessor/packFn just before emit at :13576) — none of them run
before the canvas work.

Suggested fix. An option honoured before drawImage that caps the canvas —
maxDimension or a pixel budget — scaling down while preserving aspect ratio.
Separately, createImageBitmap plus OffscreenCanvas could move the draw and
encode stages off the main thread, though bitmap acquisition and CORS handling
would still touch it, and support would need a fallback.

Happy to send a PR if this shape is acceptable.