window is not defined in SSR

[oceandrama]

While using pdfjs in frameworks with SSR like Next.js or Gatsby there is an error while build phase
ReferenceError: window is not defined

The error occurs at line 563 in ui_utils.js

Looks like all changes needs is:

const animationStarted = new Promise(function (resolve) {
  if (
    typeof PDFJSDev !== "undefined" &&
-   PDFJSDev.test("LIB && TESTING") &&
+   PDFJSDev.test("LIB && TESTING") ||
    typeof window === "undefined"
  ) {
    // Prevent "ReferenceError: window is not defined" errors when running the
    // unit-tests in Node.js/Travis.
    setTimeout(resolve, 20);
    return;
  }
  window.requestAnimationFrame(resolve);
});

There is an issue in react-pdf: wojtekmaj/react-pdf#657

[Snuffleupagus]

While using pdfjs in frameworks with SSR

What does "SSR" actually mean? Please don't use acronyms and assume that everyone immediately knows exactly what you mean.

ReferenceError: window is not defined

The error occurs at line 563 in ui_utils.js

The code in that file is not intended to run outside of a browser-context, hence it's not clear why changes are necessary here!?
(Furthermore the suggested change is not actually correct, assuming there's even something that needs to be fixed here.)

[oceandrama]

What does "SSR" actually mean

Server side rendering

[Snuffleupagus]

Server side rendering

Thanks for the clarification; but as mentioned that file isn't really intended to be used in such a situation.

Edit: Please note that the pre-processor statement looks the way it does to avoid a useless typeof window === "undefined" check in e.g. the Firefox PDF Viewer (which is why this library exists in the first place).
I suppose that the one change that we could possibly accept, assuming it's even necessary, is one which removes only the TESTING-part (and nothing else) from

pdf.js/web/ui_utils.js

Line 741 in 709c57a

PDFJSDev.test("LIB && TESTING") &&

[oceandrama]

I don't know why but the error exists and there are issues about it even in this repository:
wojtekmaj/react-pdf#657
#9888

@wojtekmaj Can you join to conversation?
@Snuffleupagus I think it will be a good progress in an attempt to solve this problem

[dolie]

I got the same problem.

[Snuffleupagus]

@timvandermeij What's your opinion here, should we make the small change outlined in #13057 (comment) or close this as wontfix given the specialized use-case?

[timvandermeij]

If the small change is the only thing necessary to make this work for those frameworks (it's not entirely clear if it is from this issue, so we'll need a verification for that), I think it would be fine to do that.

[wojtekmaj]

Another way to fix it would be to simply write

const animationStarted = new Promise(function (resolve) {
  if (typeof window === "undefined" || typeof window.requestAnimationFrame !== "function")) {
    setTimeout(resolve, 20);
  } else {
    window.requestAnimationFrame(resolve);
  }
});

[Snuffleupagus]

Another way to fix it would be to simply write

const animationStarted = new Promise(function (resolve) {
  if (typeof window === "undefined" || typeof window.requestAnimationFrame !== "function")) {
    setTimeout(resolve, 20);
  } else {
    window.requestAnimationFrame(resolve);
  }
});

That's not really an acceptable solution though, since as a general rule we don't want to add useless runtime checks in Firefox; please note #13057 (comment).

[Snuffleupagus]

@wojtekmaj A few questions here, so that we have a complete picture to evaluate possible solutions:

• What kind of PDF.js build are you using in React-PDF?
  I'm assuming you have a pdfjs-dist dependency, but which particular files/folders are you using?

• Since this issue seem limited to the situation where files, which originate in https://github.com/mozilla/pdf.js/tree/master/web, are run in Node.js[1]:
  Is there a risk that the window object itself could be incorrectly/incompletely polyfilled, and that typeof window === "undefined" thus doesn't cover all possible cases?

---

[1] Although, as mentioned previously, all files in that folder are written with the assumption that they're run in a browser context.

[wojtekmaj]

but which particular files/folders are you using?

I think the issue here was that I needed PdfLinkService to get links working in PDFs, and PDFLinkService required EventBus, which, when imported, evaluated the entire ui_utils.js unfortunately, because ui_utils isn't side effect free. I created our own custom link service now in React-PDPF 5.3.0 beta so that should no longer be an issue - at least from our side, unless someone else will try the same thing.