Pdf.js: Memory leak: some events aren't unregistered

Thank you, I think you're right. I don't think it's necessarily a memory leak, but this should be refactored a bit so that the binding/unbinding of window events is in one place only.

Seems things are not so easy, although I don't know why yet:

• the keydown listener is registered when the viewer.js script is loaded, no matter if there's a PDF or not.
• I've added the removeEventListener as I suggested. To my surprise, CMD+P doesn't do anything (except highlighting the "edit" menu for a fraction of a second). Maybe that's an OSX problem. My theory is that registering the "keydown" event automatically kills the standard key binding. If that's true, we could simply re-bind it to window.print().

BTW, here are my source code changes: https://github.com/stephanrauh/ngx-extended-pdf-viewer/commit/6f47d1bd7f790fa47872c11031fefae4e24e283e#diff-ff2d4af1f0673e3ea448a4b444ece1da

Forget about my last post - I've managed to get everything up and running. It's possible to restore the standard functionality after removing pdf.js from the DOM. Also see #10948, which is an unexpected side effect that confused me yesterday.

In pull request #11380 two out of the three registered event listeners are now also unregistered upon resetting. Only the print keydown event listener remains for this issue.

In pull request #11380 two out of the three registered event listeners are now also unregistered upon resetting.

Yes, but those events were was only fixed indirectly since it made sense for other reasons (such as consistency with other components) to allow for a PDFHistory instance to be reset.

In general though I would be very tempted to suggest WONTFIX for the PDFPrintService code, for a couple of reasons:

• This issue claims that there's memory leaks, but doesn't actually provide any evidence to back that up.
• The only embedding that the default viewer really supports is an <iframe>, where I cannot imagine that these event listeners should cause any trouble.[1]
• This doesn't affect the FirefoxPrintService at all, since it registers no events. Hence trying to "fix" this in the PDFPrintService would thus make the different PDFPrintServiceFactory interfaces "unbalanced".
• There's a number of window events being registered in web/pdf_print_service.js, and I think that you need to register them immediately upon load to not miss any events and/or not being the first event handler. Consequently, removing these event listeners may thus lead to unexpected behaviour later on.

[1] Note also http://mozilla.github.io/pdf.js/getting_started/#introduction (emphasis mine):

The viewer is built on the display layer and is the UI for PDF viewer in Firefox and the other browser extensions within the project. It can be a good starting point for building your own viewer. However, we do ask if you plan to embed the viewer in your own site, that it not just be an unmodified version. Please re-skin it or build upon it.

@Snuffleupagus I can't evade the impression you disapprove of the ngx-extended-pdf-viewer project. Is this correct? If so, why?

Just for the record: ngx-extended-pdf-viewer does build upon pdf.js. It adds 62 modifications to the core pdf.js files. It also adds a lot of additional value, especially compared to the iFrame approach. Currently, there's limited skinning. As far as I can see, almost every user is using it. Advanced skinning (i.e. Material Design and Bootstrap4) is on top of the users' wish-list, so it'll come soon.

Putting it all together, I'm astonished you stress the "re-skin or build" bit so often.

I can't evade the impression you disapprove of the ngx-extended-pdf-viewer project.

Honestly I don't even know what the "ngx-extended-pdf-viewer" project is, and won't have time to figure that out now with Christmas just around the corner, hence I obviously don't have an opinion about it :-)

Generally speaking, not singling out any particular project: The reason that the default viewer shouldn't be used as-is, is to avoid custom applications being mistaken for the built-in PDF Viewer in Firefox by virtue of looking more-or-less identical to many users.

@Snuffleupagus Thanks! That's a very good reason, something I can work with. I'll see what I can do to make "my" embedded viewer look different. In most cases, it'll look different simply because it's not a full-page viewer, but of course, I don't want to see my bugs on your bug tracker.

What I can offer is this: if someone files a bug report, and mentions "Angular", just CC me.

Best regards, and merry Christmas
Stephan

That's very nice of you, thanks! In general we mention skinning because we have seen bugs in custom deployments of PDF.js being reported here relatively often because users thought they were dealing with the official viewer when they were in fact looking at an unskinned copy of the default viewer. To avoid this, we usually mention this line, but in this case it was just to show that extending PDF.js like you're doing is actually OK/recommended, so no worries about that!

If you find issues in PDF.js, please always feel free to always report them. We have already fixed some problems based on your issues/comments, so that's very helpful.