ngx-extended-pdf-viewer: Remote server URLs don't work for `pdfDefaultOptions.assetsFolder`

Check this first

Sorry, but the nature of this problem means my answers to your three questions are:

  • Probably not.
  • Probably not.
  • Um, I don’t know how for this one…

Background info before I can describe the bug…

We are using your excellent PDF viewer in a multi-tenant Angular app (one app white-labelled and served separately for each of many customers). Without too much detail that’s irrelevant to you, just know that our architecture causes our assets path to be not relative to the site URL, but on a completely separate server.

To illustrate this, here are a couple of pretend URLs for a couple of sites using our app:

  • https://customer1.our-app.com
  • https://customer2.our-app.com

And a pretend assets URL shared by all sites:

  • https://library.our-app.com/assets

When we upgraded to your v13 (along with our upgrade to Angular v13), we could no longer load PDFs: image

We determined that this was due to the fact that your code was now trying to load the new op-chaining-support from a relative assets URL, and it couldn’t, since those aren’t there. (The browser was trying to parse our app’s error page as that JavaScript file, because of Angular default routing. THAT was confusing!)

Further research through your GitHub issue discussions taught us that we just needed to set pdfDefaultOptions.assetsFolder, so we updated our code so that it basically has this outcome:

pdfDefaultOptions.assetsFolder = 'https://library.our-app.com/assets';

This fixed the op-chaining-support problem.

However…

Describe the bug

We then got this message when trying to load: image

I determined that we were trying to load the PDF worker via a URL like https://customer1.our-app.com/https://library.our-app.com/assets/pdf.worker-2.13.491.min.js. (Note the double https.)

I found this in your source code in pdf-default-options.ts:

  workerSrc: () =>
    pdfDefaultOptions.needsES5
      ? `./${pdfDefaultOptions.assetsFolder}/pdf.worker-${getVersionSuffix(pdfDefaultOptions.assetsFolder)}-es5.js`
      : `./${pdfDefaultOptions.assetsFolder}/pdf.worker-${getVersionSuffix(pdfDefaultOptions.assetsFolder)}.js`,

(Ditto for other options – cMapUrl, sandboxBundleSrc, standardFontDataUrl.)

You’ve made the very reasonable assumption that assets are always served via a relative URL, but this doesn’t work for our particular use case.

Workaround

You’ve given us the ability to override these other options, so that’s what I’m doing. I don’t want to recalculate everything, though, so I’m doing (something like) this:

pdfDefaultOptions.assetsFolder = 'https://library.our-app.com/assets';

const newWorkerSrcReturnValue: string = pdfDefaultOptions.workerSrc().replace(/^\.\//, '');
pdfDefaultOptions.workerSrc = () => newWorkerSrcReturnValue;

// Ditto for the other options that depend on pdfDefaultOptions.assetsFolder.

And this seems to work.

Proposed solution

Make your default options functions account for a possible full remote URL in pdfDefaultOptions.assetsFolder, and leave off the ./ in that case?

But that’s up to you… Not sure if our use case is truly a one-off or not.

If you decide to just call this a “won’t fix”, I don’t blame you. But at least this is documented in your issues, in case anyone else out there happens to have a similar setup. And our workaround should be fine for us (and future them, perhaps).

But if you do decide to support this weird use case, we’ll be able to delete a bit of workaround code in the future. 🙂

And a question:

Do you know of any other complications that my workaround won’t prevent?

Version info

  • v13.0.0

Desktop (please complete the following information):

  • Probably irrelevant, but mostly Chrome

Smartphone (please complete the following information):

  • Nothing specific

To Reproduce

  • Can you provide a reproducer?

    • Sorry, I don’t think so.
  • If you really can’t provide me a reproducer, please tell me how to reproduce the behavior:

    • Hopefully the description above is sufficient.

Thank you!

  • No… thank YOU! You’ve got a great PDF viewer here – and Angular ready! 😍

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Comments: 18 (10 by maintainers)

Commits related to this issue

Most upvoted comments

@Snuffleupagus @calixteman @timvandermeij I’m receiving a lot of positive feedback for wrapping your work into a decent Angular library. It’s time to pass the kudos to you, too. Thanks a lot for creating such a great Firefox PDF viewer and even allowing other people to build upon your work! You guys rock!

(And before you ask: please don’t try to answer this particular GitHub issue - it’s specific to my Angular wrapper. I just wanted to share some of the "thank you"s I get with you).

Yes, the latest version fixes the issue! I wasn’t sure on Friday, but we have the files uploaded to our internal CDN and it all works as expected. Thanks again!

I have the same scenario. Thanks @etramell-tem for an incredibly well-documented issue, and @stephanrauh for a phenomenal library!