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.comhttps://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:

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:

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
- stephanrauh/ngx-extended-pdf-viewer#1478 allow for absolute asset URLs on a remote server — committed to stephanrauh/extended-pdf-viewer-showcase by stephanrauh 2 years ago
- #1478 allow for absolute asset URLs on a remote server — committed to stephanrauh/ngx-extended-pdf-viewer by stephanrauh 2 years ago
- #1478 allow for absolute asset URLs on a remote server — committed to stephanrauh/ngx-extended-pdf-viewer by stephanrauh 2 years ago
- #1478 allow using absolute URLs for `pdfDefaultOptions.assetsFolder` — committed to stephanrauh/ngx-extended-pdf-viewer by stephanrauh a year ago
- #1478 added Playwright tests — committed to stephanrauh/ngx-extended-pdf-viewer by stephanrauh a year ago
@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!