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

ddzingielewski commented 2 years ago

While trying to render div container with a lot of angular material chechboxes using htmlToImage.toPng i received an error: Error: Uncaught (in promise): Event: {"isTrusted":true} It seems that this error appeared after upgrading Firefox to version 97 or above (it works fine in current Chrome and Edge, and also worked fine in FF<=96.0.3). If i reduce number of components inside container: for example: from 400 to 100-200 it renders without error.

Steps To Reproduce

Here is code that reproduces bug: https://stackblitz.com/edit/angular-ivy-bq1svc Try running it from Firefox (version 97 or above) and click "Export".

Additional Context

Same behavior is when instead of mat-checkbox i use mat-table for example. On the other hand when I replace mat-checkbox with mat-radio-button the error is gone.

Your Environment

html-to-image: [e.g. 1.9.0]
OS: [Windows 10 Pro]
Browser: [Firefox 97.0.1]

faaraya commented 2 years ago

Hi everyone! It the same for me but:

I'm using htmlToImage.ToBlob and i'm not using angular material, i'm just using many components inside container and if i reduce the number of components, it works again.

html-to-image: [e.g. 1.9.0]
Browser: [Firefox 97.0.1]

mohsinmuzawar01 commented 2 years ago

Same thing happens in chrome. After the project is deployed to a secured URL but works fine on local.

mohsinmuzawar01 commented 2 years ago

Is this issue being worked upon ? When would this issue be resolved?

liveangela commented 2 years ago

Same problem~ All methods (toPng, toSvg, toCanvas...) will throw this error. But it's strange that it works for most situations, only failed for some certain ones, like making this tweet into image

Your Environment

html-to-image: [1.9.0]
OS: [MacBook Pro]
Browser: [Chrome 99.0.48]

mhamri commented 2 years ago

the stackblitz example need a try/catch to show the actual error. the error in title is wrong and is related to unhandled exception

here is the corrected one: https://stackblitz.com/edit/angular-ivy-ftzdjh

the error look like below

but my issue is the error isn't helpful and doesn't help with debugging it

I have the same issue and it happens on firefox but chromium edge is fine

should be bcs of this warning in firefox

Element.setCapture() is deprecated. Use Element.setPointerCapture() instead. For more help https://developer.mozilla.org/docs/Web/API/Element/setPointerCapture

biiibooo[bot] commented 2 years ago

Hiya! This issue has gone quiet. Spooky quiet. 👻 We get a lot of issues, so we currently close issues after 60 days of inactivity. It’s been at least 20 days since the last update here. If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not-stale" to keep this issue open! As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request.

Thanks for being a part of the Antv community! 💪💯

mhamri commented 2 years ago

bump!

biiibooo[bot] commented 2 years ago

Hiya! This issue has gone quiet. Spooky quiet. 👻 We get a lot of issues, so we currently close issues after 60 days of inactivity. It’s been at least 20 days since the last update here. If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not-stale" to keep this issue open! As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request.

Thanks for being a part of the Antv community! 💪💯

gecko-steffen commented 2 years ago

Bumpety bump

biiibooo[bot] commented 2 years ago

Hiya! This issue has gone quiet. Spooky quiet. 👻 We get a lot of issues, so we currently close issues after 60 days of inactivity. It’s been at least 20 days since the last update here. If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not-stale" to keep this issue open! As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request.

Thanks for being a part of the Antv community! 💪💯

mhamri commented 2 years ago

bump

weix77 commented 2 years ago

I also stumbled across this problem. It seems to be somehow related to the number of elements inside the element being exported.

mhamri commented 2 years ago

but it doesn't have any issue in chrome. it's only happen in the firefox

kaushalm commented 2 years ago

bump

biiibooo[bot] commented 2 years ago

Hiya! This issue has gone quiet. Spooky quiet. 👻 We get a lot of issues, so we currently close issues after 60 days of inactivity. It’s been at least 20 days since the last update here. If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not-stale" to keep this issue open! As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request.

Thanks for being a part of the Antv community! 💪💯

mhamri commented 2 years ago

bump

kaushalm commented 2 years ago

if it helps anyone, here is the root cause that solved the issue for me, my dom had 'elementtiming' attribute attached to all the nodes for some performance capturing and "elementtiming" attribute is not compatible with all types of nodes like canvas etc.

In my case this error was coming on firefox and on chrome in some cases it was crashing the browser tab.

biiibooo[bot] commented 2 years ago

Hiya! This issue has gone quiet. Spooky quiet. 👻 We get a lot of issues, so we currently close issues after 60 days of inactivity. It’s been at least 20 days since the last update here. If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not-stale" to keep this issue open! As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request.

Thanks for being a part of the Antv community! 💪💯

mhamri commented 2 years ago

aya!

voxivoid commented 2 years ago

I also got this error on firefox, despite it working perfectly on chrome

ehsantekgenisys commented 2 years ago

any update on this issue?

lwstudy commented 2 years ago

这个问题怎么产生的呢？我在chrome104也会遇到，但是在不同画图元素时，有的能会error有的不会， 1、我在用antv/x6中的vue-shape时使用到htmlToImage.toPng()没什么问题， 2、但是在复杂的节点分组连接桩时，会产生该error，我猜测可能是groups中定义的tagName元素（rect、text、image）导致。【也可能是别的，还是想知道到底发生了什么导致】

rooby commented 2 years ago

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.

AlexSirenko commented 1 year ago

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:

use toSvgToString but for chunks (define several nodes and the get svgs for every node)
Merge svg strings into one string.
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.

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

lucian55 commented 1 year ago

bump

ShivamRealcoderz commented 1 year ago

Hiya! This issue has gone quiet. Spooky quiet. 👻 We get a lot of issues, so we currently close issues after 60 days of inactivity. It’s been at least 20 days since the last update here. If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not-stale" to keep this issue open! As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request.

Thanks for being a part of the Antv community! 💪💯

not-stale

thesftechie commented 1 year ago

toSvg works in my case when I encountered this error.

I found the issue with mine was having imported a font with @font-face. I removed the font requirement from one of my use cases but it is required for the other.

I think this is an external resource issue with the svg generated. When I toSvg and then try to create an img with the src as the dataUrl, I hit my debugger statement in onerror for the img. When I remove the font-face requirement, I load the img without issue.

thesftechie commented 1 year ago

I actually got it to work. It turns out I had a duplicate @font-face declaration. Once I got it down to 1 @font-face, it worked like a charm for the other methods as well.

thesftechie commented 1 year ago

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."

dv0open commented 1 year ago

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.

chendind commented 1 year ago

所以这问题就没人管了是嘛，这尼玛的仓库还3000多颗星星呢

andymcmullan commented 1 year ago

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:

svgDataUri = htmlToImage.toSvg()
Convert svgDataUri to a Blob
Convert the Blob to an object URL (URL.createObjectURL)
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.

ek-work commented 11 months ago

Same thing happening with our app as well. @andymcmullan I tried the workaround you proposed, but ran into the same error when attaching the objectURL to the image element. Could you provide a little more detail what you did as a workaround? Thanks!

andymcmullan commented 11 months ago

Same thing happening with our app as well. @andymcmullan I tried the workaround you proposed, but ran into the same error when attaching the objectURL to the image element. Could you provide a little more detail what you did as a workaround? Thanks!

The basics are like this:

const svgDataUri = await htmlToImage.toSvg(element, options);
const rawSvg = decodeURIComponent(svgDataUri.split('data:image/svg+xml;charset=utf-8,')[1]);
const svgBlob = new Blob([rawSvg], { type: 'image/svg+xml;charset=utf-8' });
const svgObjectUrl = URL.createObjectURL(svgBlob);
const img = new Image();
img.src = svgObjectUrl;

ek-work commented 11 months ago

@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.

pmoleri commented 10 months ago

Hi. Checking the same problem.

My findings are:

css custom properties (aka css variables) are listed in element computed style in Firefox but not in Chrome, plus they're inherited by default. When a library does extensive use of css variables it bloats the svg result. As explained in the previous comment by @ek-work. Note that Chrome doesn't yet list them, but it may at some point Chrome Issue 949807: getComputedStyles does not include CSS Custom Properties.
Firefox has an URL limit of around 32MB if we try to use longer urls as img.src or even new URL() it throws an error.
html-to-image uses data: url because otherwise Chrome taints the canvas and can't produce the image, but Firefox doesn't have this issue and it can use the more performant createObjectUrl. As explained already by @andymcmullan

All things combined result in Firefox throwing error much "sooner" than Chrome.

I think the situation can be improved a lot by:

Don't clone CSS custom properties (starting with --) when they're inherited (same value as parent).
Add an option to allow use createObjectUrl instead of data: url. If we make it default to this in Firefox it will prevent new users having to find this issue the hard way.

@bubkoo would you accept a PR addressing these points?

bubkoo / html-to-image