html-to-image: "Error: Uncaught (in promise): Event: {"isTrusted":true}" while rendering container in FF

bump. Why isn’t the bot removing the stale tag?

Seems like there is a history on this repo of issues in this queue getting ignored and then closed by the stale bot for no good reason. It’s fine if it takes a long time to get around to investigating issues, but automatically closing them because no one has got to them yet is extremely frustrating.

In case someone else has the same problem as I: For me, this error appeared, when I had an <img> with an empty src attribute (src=‘’). Removing the image (or adding a valid src) solved the problem.

I think I know the problem with the first. The svg (after prettier) is ~30MB, the flat dataUrl is ~40MB. After updating to have a much smaller list, the png generated without issue.

Length limitations

Browsers are not required to support any particular maximum length of data. For example, the Opera 11 browser limited URLs to 65535 characters long which limits data URLs to 65529 characters (65529 characters being the length of the encoded data, not the source, if you use the plain data:, without specifying a MIME type). Firefox version 97 and newer supports data URLs of up to 32MB (before 97 the limit was close to 256MB). Chromium objects to URLs over 512MB, and Webkit (Safari) to URLs over 2048MB.

MDN Reference for quote

It seems like in general this error is browser limitations around dataUrls and therefore not really a bug for this project.

I do agree the error message could be more clear though. I’m sure we could add a message when img.onerror here to say “There may be a browser limitation or data issue encountered when creating an img element needed to render the result.”

@andymcmullan Thanks Andy! I missed the decodeURIComponent step in my work, but once included it worked like a charm - thanks again.

FYI: In case it helps anyone else . . . We use a library which contains a large number of css variable references at the :root {...} level. In Chrome|Edge, when running toSVG, the css styles never included those css variable references. But in Firefox, not only were those css variable references retained, they were duplicated for every node that was cloned, and when this was a table reference node, every cell in that table had a copy of these css variable references causing severe css bloat in the svg.

Our fix was to use Andy’s suggestion (objectUrl instead of dataUrl). But in addition, we also removed all of the the root: {} level css elements which we knew were not being used. A bit dangerous - yes, but for our use-case we knew that none of those css variables retained in firefox were needed for the svg to be properly rendered.

const svgDataUriPrefix = "data:image/svg+xml;charset=utf-8,";
let decodedSvg = decodeURIComponent(svg.split(svgDataUriPrefix)[1]);
decodedSvg = decodedSvg.replace(/--cssvarname-.*?;/g, "");

I would propose an additional filter option (i.e. like the node element filter) that would operate on the svg-output - some sort of SVG-optimze filter function - that could be added as an option. That would be enough - at least in our case, to work around the firefox problem without having to extract/copy code as a workaround in html-to-image.

I encountered this issue when converting a complex page to PNG on Firefox.

In my case it was due to breaching the Firefox 32 MByte data URI limit on Firefox, as mentioned in other comments.

With the hints on this thread I was able to work around the issue by getting html-to-image to do the hard part (HTML to SVG), via the toSvg() function, then taking over the SVG-to-PNG part by using a similar mechanism to html-to-image, but instead of attaching the SVG to an Image element using a data URI I use an object URL instead, which has much higher size limits.

So my code is roughly:

1. svgDataUri = htmlToImage.toSvg()
2. Convert svgDataUri to a Blob
3. Convert the Blob to an object URL (URL.createObjectURL)
4. Attach the object URL to an Image element, then follow the normal html-to-image steps - draw it on a canvas, then convert the canvas to a Blob, then Blob to a data URI.

Unfortunately this approach doesn’t seem to work for Chrome, which complains about the canvas being tainted. So I’ve had to special case usage of this code for Firefox only, and use the standard toPng() for other browsers.

The bug is related to firefox image limitations (some sort of max height is 32676px). When canvas/image have more height - Firefox throws an error. Workaround is to:

1. use toSvgToString but for chunks (define several nodes and the get svgs for every node)
2. Merge svg strings into one string.
3. Make blob from there.

Use patch-package if needed.

export async function toSvgByChunks(nodes, options = {}) {
const svgsStrings = (await Promise.all(nodes.map(node => toSvgString(node, options)))).join('');

return new Blob([`<svg><foreignObject>${svgsStrings}</foreignObject></svg>`], { type: 'image/svg+xml' });
}

The same can be done to convert to image.

1. Create images for chunks (check toCanvas method).
2. Draw images in canvas (check toCanvas method).
3. Canvas to blob (but not use canvas.toBlob) method.