Chrome is stuck after generating a PDF

[fpegios]

This is the code I am using

const generatePDF = async () => {
const element = contentRef.current
const canvas = await html2canvas(element, {
useCORS: true, // For external images
allowTaint: true,
scrollX: 0,
scrollY: 0,
})

const imgData = canvas.toDataURL('image/png')
const pdf = new jsPDF('p', 'mm', 'a4')

const imgWidth = 210 // A4 width in mm
const pageHeight = 295 // A4 height in mm
const imgHeight = (canvas.height * imgWidth) / canvas.width
let position = 0

pdf.addImage(imgData, 'PNG', 0, position, imgWidth, imgHeight)

pdf.save('my-react-app.pdf')

}

The issue appeared after updating to Google Chrome 138

[erik-grubbs]

Commenting because I'm experiencing a similar issue and looking for tips, although I think it has more to do with html2canvas then jsPDF.

[RomainVernoux]

We experienced a similar issue. I think this is a Chrome bug or an html2canvas issue rather than related to jsPDF :)

Indeed after the Chrome 138 update, we noticed a considerable drop in performance of this method
await html2canvas(targetElement).

When digging more, we found out that html2canvas is actually cloning the whole document containing targetElement, not just targetElement itself: https://github.com/niklasvh/html2canvas/blob/master/src/dom/document-cloner.ts#L69

While cloning, all styles are duplicated and inlined with a style attribute on each cloned element, which generates a huge DOM if the parent document is large: https://github.com/niklasvh/html2canvas/blob/master/src/dom/document-cloner.ts#L321

We fixed it by cloning only the parent and child elements of the target element, discarding the siblings. Hopefully this does not affect the styling of the targetElement you want to clone :)

await html2canvas(targetElement, {
  ignoreElements: (element) => {
    // We don't want to clone the element when
    const ignored =
      // The targetElement is not a descendant of this element
      !element.contains(targetElement) &&
      // This element is not a descendant of the targetElement
      !targetElement.contains(element) &&
      // This element is not the targetElement itself
      targetElement!== element;
    return ignored;
  },
})

Maybe this can help?

[erik-grubbs]

We experienced a similar issue. I think this is a Chrome bug or an html2canvas issue rather than related to jsPDF :)

Indeed after the Chrome 138 update, we noticed a considerable drop in performance of this method await html2canvas(targetElement).

When digging more, we found out that html2canvas is actually cloning the whole document containing targetElement, not just targetElement itself: https://github.com/niklasvh/html2canvas/blob/master/src/dom/document-cloner.ts#L69

While cloning, all styles are duplicated and inlined with a style attribute on each cloned element, which generates a huge DOM if the parent document is large: https://github.com/niklasvh/html2canvas/blob/master/src/dom/document-cloner.ts#L321

We fixed it by cloning only the parent and child elements of the target element, discarding the siblings. Hopefully this does not affect the styling of the targetElement you want to clone :)

await html2canvas(targetElement, {
  ignoreElements: (element) => {
    // We don't want to clone the element when
    const ignored =
      // The targetElement is not a descendant of this element
      !element.contains(targetElement) &&
      // This element is not a descendant of the targetElement
      !targetElement.contains(element) &&
      // This element is not the targetElement itself
      targetElement!== element;
    return ignored;
  },
})

Maybe this can help?

Really appreciate the help, but sadly this loses all the styling. It was definitely faster but still 2x to 3x slower than the previous Chrome versions. This gives me a direction to debug though, so thanks again.

I did open a chromium issue just to see if any other wayward souls come upon this.

[Smit24-git]

we've been impacted as well. chrome marked as intended behavior which make sense given their explanation on this thread mentioned above. I did the same what reporter mentioned on that thread. I had to pull the HTML2CANVAS code and remove all custom variables from the style object. It still takes time, but a lot less (>50% improvement).

This workaround works short term. Given the amount of open issues on html2canvas and no updates past few years, I am very much inclined towards switching to different library.

[erik-grubbs]

To update anyone looking at this, the problem with Chrome 138 is that it enabled enumerating custom CSS properties in getComputedStyle. So unsurprisingly Chromium isn't going to revert it because it's working as expected.

What I did was make a fork of html-to-image and patched the css cloning to filter out custom properties and that got performance back to expected, but that is a short term not long term fix, recommend trying a different html to image library (other issues have recommended Snapdom).

As it was the whole time, this isn't a jsPDF issue so I feel like parallax can close this.