Previously we could open doc files with the Web Viewer but now we are getting max call stack errors on OfficeWorker.js

Uncaught (in promise) RangeError: Maximum call stack size exceeded
at Hrf (eval at a.loadCompiledBackend (OfficeWorker.js:8), :12:1077184)
at func (eval at a.loadCompiledBackend (OfficeWorker.js:8), :1:28135)
at callRuntimeCallbacks (eval at a.loadCompiledBackend (OfficeWorker.js:8), :1:22078)
at ensureInitRuntime (eval at a.loadCompiledBackend (OfficeWorker.js:8), :1:22578)
at doRun (eval at a.loadCompiledBackend (OfficeWorker.js:8), :36:15058)
at run (eval at a.loadCompiledBackend (OfficeWorker.js:8), :36:15374)
at runCaller (eval at a.loadCompiledBackend (OfficeWorker.js:8), :36:13965)
at removeRunDependency (eval at a.loadCompiledBackend (OfficeWorker.js:8), :1:26164)
at applyMemoryInitializer (eval at a.loadCompiledBackend (OfficeWorker.js:8), :36:12892)
at useRequest (eval at a.loadCompiledBackend (OfficeWorker.js:8), :36:13416)

This is the error we are getting when launching a doc/docx file via webviewer, it is now getting stuck at loading at 100% with what seems to be a timeout issue when calling OfficeWorker.js methods. Previously (about a week ago) customers are able to load and markup with no problems. Has this been deprecated? This is the old version of PDFTron Web Viewer btw.

{edit] On further testing in Firefox version 88 it’s not working. But when I rollbacked/downgraded to previous version 86 it now works. There seemed to be a recursion check implemented on latest browser versions now that is not working well with OfficeWorker component of web viewer.

Hi Michael,

Thank you for contacting us about this. Is this issue related to a single office file, or is it an issue with all office files with the updated version of Firefox? In addition, is the issue related to Firefox only, or can you observe this issue on other browsers?

Could you also please provide us with the version of WebViewer you are running?

It would probably be best if we continue this discussion via email. Please submit this information to:

Thank you.

Hi, yes it’s happening for all office files as of the moment. We tested running on older browser versions and its working without fail. Here is the build version [WebViewer_3.1.0.63771]

Would like to gently follow up on the needful? Any news?

Hi Michael,

I think you need to upgrade the WebViewer to the latest version, you can download WebViewer V7.3.1 from here:

Let me know if you still seeing this error after upgrading.


I’ve installed v7.3.1 and the iPad will still give this RangeError.
This is happening since latest ios update 14.5.1
edit: By iPad I mean safari or Webview on ios.

I tested using iPad Pro + Safari on our demo site: and I didn’t see any errors.
So my questions are:

  1. Can you reproduce the error on our demo site: If so, what’s your device and your system version + safari version.
  2. If not, can you provide an access to your application?
  3. If you cannot give access, is there a way for us to see this error on our side? Please include step-by-step instructions on how to reproduce.
  4. Can you see the same error on other devices/browsers?


Hi and thanks for the reply.

  1. The error is not reproduced on the demo site. This points toward a different configuration that could trigger the issue.
    The device used is an iPad 5th gen running on ios 14.5.1 on safari.
    The same happens on the mac os 11.3.1 with safari 14.1
    I want to point out that this never occurs on pdf files, only .docx that I can see so far.
    The error occurs
    We do not use server-side rendering.

  2. Unfortunately, our software requires specific access that can’t be granted easily. If I get an access i’ll let you know.

  3. While I can’t easily provide a step by step, I can provide our pdftron configuration and response header for the file being served:

licenseKey: […],
annotationUser: […],
css: […],
path: ‘…/js/lib/WebViewer/lib’,
extension: ‘DOCX’,
filename: ‘601-1100403-2.DOCX’,
initialDoc: Download.srf?Context=General,
isReadOnly: true,
}, $("#documentViewer")[0]).then( instance => {

    console.log('after init This gets hit');

   instance.docViewer.on('annotationsLoaded', () => {
      console.log('after annot. This is never hit');


HTTP/1.1 200 OK
Access-Control-Allow-Methods: GET, POST
Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Access-Control-Allow-Origin: *
Date: Thu, 13 May 2021 13:57:15 GMT
Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept, x-api-version
Content-Disposition: attachment; filename=“601-1100403-2.DOCX”
Content-Length: 17670
Connection: close

  1. The same works perfectly on PC Chrome/Firefox, Android Chrome.

Lastly, here’s the full error along with a warning coming from OfficeWorker.js (The guid-like thing in the error is a child of OfficeWorker):

[Warning] There may be some degradation of performance. Your server has not been configured to serve .gz. and .br. files with the expected Content-Encoding. See for instructions on how to resolve this. (OfficeWorker.js, line 43)

[Error] Unhandled Promise Rejection: RangeError: Maximum call stack size exceeded.

eSf (c0e31672-ee64-439c-bf04-818ce079aa1d:23:334331)

func (c0e31672-ee64-439c-bf04-818ce079aa1d:1:29186)

callRuntimeCallbacks (c0e31672-ee64-439c-bf04-818ce079aa1d:1:22083)

ensureInitRuntime (c0e31672-ee64-439c-bf04-818ce079aa1d:1:22599)

doRun (c0e31672-ee64-439c-bf04-818ce079aa1d:36:16033)

run (c0e31672-ee64-439c-bf04-818ce079aa1d:36:16337)

runCaller (c0e31672-ee64-439c-bf04-818ce079aa1d:36:14926)

removeRunDependency (c0e31672-ee64-439c-bf04-818ce079aa1d:1:26173)

applyMemoryInitializer (c0e31672-ee64-439c-bf04-818ce079aa1d:36:13869)

useRequest (c0e31672-ee64-439c-bf04-818ce079aa1d:36:14396)