Sure, here it is. @tgordon
You can open and close the modals multiple times to see your memory mounting until crashing.
@tgordon any news?
This is still an issue for us.
Hey CarlosVergikosk,
Apologies for the delay, and thank you for the sample.
I think it’s important to note from the sample, you’re not actually calling the dispose when you’re closing the modal. The usage of memorization and useCallback (which includes caching) is also troublesome in this case as well (although I cant pinpoint if this is the reason why)
I suggest you modify the app to actually close WebViewer on modal close, instead when instantiating a new WebViewer.
Best regards,
Tyler
Hi @tgordon, after speaking with Apryse directly, we managed to identify that there is indeed a memory leak on their premium viewer and subsequentially on this too.
It can only be reproduced if you have browser extensions that interfere with the DOM and prevent garbage collection from the viewers.
Maybe that’s why you couldn’t reproduce it.
sandbox: https://github.com/jgozner/webviewer-sandbo
Install an extension like Grammarly, and you will reproduce it.
I hope this helps people in the same situation, and that you can pump it on your team so this can get fixed asap.
Are there any updates on this issue. I believe that I may have encoutered the same memory leak issue despite using the dispose calls.
I spoke with people from Apryse directly, and they admitted that there is indeed a memory leak issue when you have an extension like Grammarly installed that prevents their viewer from cleaning its instances correctly.
Since no one seemed to care about this issue, we had to search for other solutions to render PDFs. I can recommend using Adobe PDF Embed API.