TextLayerBuilder._bindEvents: this.cancel() should have been called when the page was reset, or rendering cancelled.

[dertsaf]

If click on showPresentationModeButton, the following error will show up:

TextLayerBuilder._bindEvents: this.cancel() should have been called when the page was reset, or rendering cancelled.

_boundEvents.pageCancelled	@	viewer.js:10606
	(anonymous)	@
	dispatch	@
	cancelRendering	@
	reset	@
	update	@
	_setScaleUpdatePages	@
	_setScale	@
	set	@
	webViewerResize	@
	(anonymous)	@
	dispatch	@
	_boundEvents.windowResize	@
	push../node_modules/zone.js/dist/zone.js.ZoneDelegate.invokeTask	@
	onInvokeTask	@
	push../node_modules/zone.js/dist/zone.js.ZoneDelegate.invokeTask	@
	push../node_modules/zone.js/dist/zone.js.Zone.runTask	@
	push../node_modules/zone.js/dist/zone.js.ZoneTask.invokeTask	@
	invokeTask	@
	globalZoneAwareCallback	@

Steps for reproduce:

1. Check out repository
2. Click the button "Show PDF" -> click the button "back" -> again click the button "Show PDF" ->
   click showPresentationModeButton.

P.S.
The error shows up only if you came from another component using router. If you refresh the page and click on showPresentationModeButton then nothing will happen.

P.S.S.
I tried to upload the reproduction on some sandbox platform as stackblitz, but unfortunately I failed to add dependencies from node_modules/ngx-extended-pdf-viewer/assets/ as it doesn't support (or I didn't find how) changes in scripts in angular.json

[stephanrauh]

If anybody knows a better approach to embed the asset folder, please tell me. I can't believe that the Angular team really doesn't have a solution for additional resource files in a library. Any help welcome!

[stephanrauh]

I've started to work on your bug report. Unfortunately, your recipe isn't that simple, so the current state of affairs is that I've opened two related tickets (#15, #16) without solving your bug. Stay tuned!

[stephanrauh]

Oops - I didn't notice you've provided a reproducer. When reading the mail sent by GitHub, the link is a detail that gets lost. Sorry!

[stephanrauh]

I've managed to reproduce the bug. However, I don't see any problems apart from the error message in the log file. What about you - is anything broken on your machine after the error message occurs?

[stephanrauh]

Side observation: When I hit CMD+F, a popup I assume to be the "find" menu appears. (I can only guess - I only speak a few words of Czech). When I enter a word like "the" or "such", there's no search result. I'm absolutely sure these words occur frequently in the document, so I'm puzzled. Plus, the search popup shouldn't show because you've deactivated it via [showFindButton]="false". This might be worth another ticket.

[stephanrauh]

Back to your bug report. At the moment, I suspect it's only a nuisance. Plus, nobody will ever detect it until looking at the JavaScript console. Is this correct?

The bug itself seems to be caused by Mozilla's pdf.js implementation. So I believe you should report the bug at their repository. However, I'm afraid it's difficult to convince them it's there bug unless you provide a reproducer that doesn't use <ngx-extended-pdf-viewer>.

[dertsaf]

I've managed to reproduce the bug. However, I don't see any problems apart from the error message in the log file. What about you - is anything broken on your machine after the error message occurs?

Yes, also buttons next and previous seem to be broken. The buttons skip some pages after they've been clicked.

[stephanrauh]

I can confirm that. Page navigation is broken.

[dertsaf]

Also, I've just found another bug.
If console (in Chrome) gets opened/closed (should be closed/opened before) after clicking the back button (see step 2 in reproduction), shows up the following error:

ERROR TypeError: Cannot read property 'div' of undefined
at backtrackBeforeAllVisibleElements (scripts.js:69558)
at getVisibleElements (scripts.js:69605)
at PDFViewer._getVisiblePages (scripts.js:75066)
at PDFViewer.update (scripts.js:75082)
at webViewerScaleChanging (scripts.js:68377)
at scripts.js:69797
at Array.forEach ()
at EventBus.dispatch (scripts.js:69796)
at PDFViewer._setScaleDispatchEvent (scripts.js:75469)
at PDFViewer._setScaleUpdatePages (scripts.js:75502)

[stephanrauh]

I suspect there are two or three different problems here:

• the original _bindEvents bug
• the Cannot read property bug (which indicates a timing problem: the PDF viewer is rendered when it's invisible - and that's something the authors at Mozilla's didn't consider)
• the multiple-page pagination bug.

The latter is caused by initializing the PDF viewer twice. When you click the "hide/show" buttons once, the "next" button jumps two pages ahead; click the buttons again, and "next" scrolls you three pages forward; and each new "hide/show" sequence increases the pagination distance agan.

[stephanrauh]

Parts of the PDFViewer remains in memory even after being hidden. The bugs seem to be related to mozilla/pdf.js#10021.

[stephanrauh]

I may have found something. It's only a partial solution, because there's still a memory leak, but it probably solves a problem or two. Add these lines before hiding the PDF file:

  back() {
    (<any>window).PDFViewerApplication.unbindEvents();
    (<any>window).PDFViewerApplication.unbindWindowEvents();
    (<any>window).PDFViewerApplication.cleanup();
    (<any>window).PDFViewerApplication.close();
    this.router.navigateByUrl('dashboard');
  }

If this approach solves or meliorates your bugs, I'll add it to the ngx-extended-pdf-viewer core.

However, I don't have any clue to to get rid of the PDFViewer instances accumulating in memory. Any suggestions?

[dertsaf]

I may have found something. It's only a partial solution, because there's still a memory leak, but it probably solves a problem or two. Add these lines before hiding the PDF file:

  back() {
    (<any>window).PDFViewerApplication.unbindEvents();
    (<any>window).PDFViewerApplication.unbindWindowEvents();
    (<any>window).PDFViewerApplication.cleanup();
    (<any>window).PDFViewerApplication.close();
    this.router.navigateByUrl('dashboard');
  }

If this approach solves or meliorates your bugs, I'll add it to the ngx-extended-pdf-viewer core.

However, I don't have any clue to to get rid of the PDFViewer instances accumulating in memory. Any suggestions?

As for me this solution solves all three different problems.
Please add it to the ngx-extended-pdf-viewer core.

Thanks!

[stephanrauh]

I'll close the ticket, opening a follow-up ticket for the memory leak.

[Srimugan]

Print Container and file Input Element appending at the document body each time when navigate changes from any page to this page.