Ngx-extended-pdf-viewer: "window.PDFViewerApplication.eventBus is null" when loading from a file or base64 pdf

Created on 3 May 2019  路  17Comments  路  Source: stephanrauh/ngx-extended-pdf-viewer

When trying a minimal example to test the plugin out I get this error, when I'm loading from a file or from a Base64 encoding. Ideally I would like to load the Base64 representation.

Here is the error itself:

ERROR TypeError: "window.PDFViewerApplication.eventBus is null"
    initTimeout ngx-extended-pdf-viewer.js:314
    Angular 7
core.js:15724

I am running this on Windows 10

I have created a repo in which I have reproduced the bug. The repo includes a base64 encoded pdf.
Here it is https://github.com/Stromwerk/pdf-viewer-reproducer

Confirmed Solved documentation

Most helpful comment

I've added more flexibility to the [src] attribute. Now it accepts ArrayBuffers, Uint8Arrays and - of course - URL strings.

If the URL is unuasually long (> 980 characters), ngx-extended-pdf-viewer checks if it's an Base64 string. If that's likely, it print a warning to the console, telling you to use the new [base64Src] attribute instead.

Which is the second news: you don't have to wrap your base64 string if you update to version 0.9.21 or above. Using [base64Src] does the trick just as well.

I've published 0.9.21 just a few minutes ago, so it should be available to your npm soon.

All 17 comments

I'll have a look ASAP. Thanks for providing a reproducer!

I haven't solved the problem yet, but I'm pretty sure it has something to do with URLs and the atob() function. At my company project, we've loaded the image as a Blob. So all we had to do was to call pdf = URL.createObjectURL(input);

It doesn't work yet, but I thought of something along these lines:

````TypeScript
export class AppComponent {
public pdf: string = AppComponent.base64ToUint8(pdfBase64);
static base64ToUint8(base64: string): string {
const raw = window.atob(base64);
const rawLength = raw.length;
const array = new Uint8Array(new ArrayBuffer(rawLength));

for (let i = 0; i < rawLength; i++) {
  array[i] = raw.charCodeAt(i);
}
const blob = new Blob([array], { type: 'application/pdf' });
return URL.createObjectURL(blob);

}
}
````

TODO to myself: document how to deal with Blobs and Base64 files.

The secret is to pass an ArrayBuffer to the url parameter:

@Component({
  selector: 'app-root',
  templateUrl: './app.component.html',
  styleUrls: ['./app.component.css']
})

export class AppComponent {
  public base64 = this.base64ToArrayBuffer(pdfBase64);

  private base64ToArrayBuffer(base64: string) {
    const binary_string = window.atob(base64);
    const len = binary_string.length;
    const bytes = new Uint8Array(len);
    for (let i = 0; i < len; i++) {
      bytes[i] = binary_string.charCodeAt(i);
    }
    return bytes.buffer;
  }
}
      <ngx-extended-pdf-viewer  [src]="base64">
      </ngx-extended-pdf-viewer>

I've added your demo to the test application of ngx-extended-pdf-viewer (see https://github.com/stephanrauh/ngx-extended-pdf-viewer/commit/580527b1833b7138720c2181fd2f45bde614c39c)

I've added more flexibility to the [src] attribute. Now it accepts ArrayBuffers, Uint8Arrays and - of course - URL strings.

If the URL is unuasually long (> 980 characters), ngx-extended-pdf-viewer checks if it's an Base64 string. If that's likely, it print a warning to the console, telling you to use the new [base64Src] attribute instead.

Which is the second news: you don't have to wrap your base64 string if you update to version 0.9.21 or above. Using [base64Src] does the trick just as well.

I've published 0.9.21 just a few minutes ago, so it should be available to your npm soon.

Thank you for your quick response and action into allowing base64 pdf files to be loaded. Unfortunately I was unable to test this earlier and now when I try the updated package I still get the error mentioned in the title of the issue. I have tested in both Firefox and Chrome on Windows 10 machines.

I get this error even when trying to load a regular pdf file which I have added in the assets folder.

I have resolved the issue by adding delayFirstView="250"

Awesome. This delayFirstView thing is giving me the creeps. :) But I'm happy it works now!

Unfortunately when I tried the plugin in the final app I want to use it in I can't get the file to be loaded. I am getting the error again, and delayFirstView isn't helping.

The scenario is that there is pdf component which is going to use the ngx-extended-pdf-viewer and the idea is to pass the pdf to the component, however when I tried inserting the ngx-extended-pdf-viewer and setting the pdf value I still get the mentioned error.

Just for the sake of completeness: do you use the new base64 attribute?

Yes, I have tried with both src and base64src, both give me the same error.

That's really strange. With so little information, I don't have a clue how to help you. Maybe you manage to create another reproducer?

I am trying, however I'm not able to reproduce the issue in another project.

I don't want to loose you to another library :) - but still, I'd like to invite you to try https://www.npmjs.com/package/ng2-pdfjs-viewer. This is a library using a much simpler and more robust approach (iFrames). Does your PDF file show using Codehippie's library?

It seems this is a duplicate of #52. The error was differently worded because I am using Firefox. I decided to try Chrome and saw the differently worded error, which lead me to #52. When I use useBrowserLocale="false" the pdf loads, however some times the pdf-viewer is loaded, but there is no pdf - it's blank - and there are no errors in the console. I am really going to try to reproduce the issue somewhere where you can also see it.
However I am a bit confused with the locales, I'm going to need different locales, how should I got about loading them?

Update: It seems that useBrowserLocale="true" also prevents the error from showing, however as I said the pdf isn't always loaded.

So I figured it out. The loading of the pdf was done in ngAfterViewInit, when I moved it into ngOnInit it loaded correctly. Also delayFirstView="250" useBrowserLocale="true" are required, otherwise the error shows up.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

i7i5 picture i7i5  路  3Comments

ekselys picture ekselys  路  5Comments

leo6104 picture leo6104  路  3Comments

4vitek picture 4vitek  路  5Comments

JaceAD picture JaceAD  路  7Comments