Webviewer does not load documents on Safari

Technical Support WebViewer
, , ,
1

WebViewer Version: 11.0.0 (tested on 11.2.0 aswell)

Do you have an issue with a specific file(s)?
Maybe, tested with multiple files thus unlikely (see below)
Can you reproduce using one of our samples or online demos?
Yes
Are you using the WebViewer server?
No
Does the issue only happen on certain browsers?
Yes (Safari Version 18.2 (20620.1.16.11.8))
Is your issue related to a front-end framework?
No
Is your issue related to annotations?
No

Im unable to load documents on Safari when setting useDownloader: false
While this happens in our React based project I was able to reproduce with

I added useDownloader: false and voila Safari is stuck showing a loading spinner forever.

Same happens for non-linearized files e.g. here: https://pdfobject.com/pdf/sample.pdf
of course now even useDownloader: true doesn’t work as the file is not linearized, nor does the server work with byte-request headers.
[Warning] Could not use incremental download for url https://pdfobject.com/pdf/sample.pdf. Reason: Could not retrieve Content-Range header. (webviewer-core.min.js, line 244)

The only thing which seems to work is a linearized pdf with useDownloader: true.
However we want to support cases where useDownloader: false or non linearized pdfs work.

1 Like
2

Hi there,

Using Safari, I am able to open the URL provided using downloader false:

image
image1920×880 166 KB

By default, useDownloader will be true, so you don’t have to explicitly set this for linearized documents. Using useDownloader: false should be for when you cannot support byte range request for linearized documents:

When you are unable to load the document, are there any errors in the console (aside from the warning) or failed network requests?
Can you share a minimal runnable sample project?

Best regards,
Kevin

1 Like
3

Hey Kevin,

I noticed that this happens after developing in Safari for some time. It may have to do with hot reloading in our current framework (nextjs) which may intefere with proper resource cleanup. After I restarted Safari it started working again.

Regarding the runnable example, I can literally reproduce this issue with the given repo and just adding the useDownloader line + trying out different pdfs.

Notably, even when having the original nextjs application running in a different tab it seems to mess up the simple demo in another tab and persists until I close the development tab.
Maybe it’s just some throttle mechanism of Safari ?

1 Like
4

Hi there,

I was unable to reproduce using the above project as is or with the react sample project (GitHub - ApryseSDK/webviewer-react-sample: Sample to demonstrate integrating WebViewer into React). I’ve tried with a new tab, and about a dozen documents each, but there was no crash or any instances of failed loading of the document.

For reference, I was using Safari ‘Version 17.5 (19618.2.12.11.6)’. Like you mentioned, this is likely an issue with hot reloading and some resources may not be fetched correctly.

Best regards,
Kevin

1 Like
5

So unfortunately the issue persists and im now im pretty sure that a memory leak is involved aswell.

I have the following simple scenario:

  • open a pdf
  • close + cleanup the viewer (this happens in our react app with unmounting the viewer component + calling dispose, closeDocument etc.)
  • reopen the viewer for a different or the same pdf (doesnt seem make a difference)
  • the webviewer is stuck + the documentLoaded listener never gets called
  • the loading progress of the loadDocument is stuck at 0.5
  • the memory footprint of the safari tab increases with every open

I modified the example repo from above by simply adding a toggle button and closing + open the viewer. I can reproduce this issue reliable everytime without anything else besides the demo open.

Only the initial open works, any subsequent hide + show only increases the memory footprint.

Its critical for our use case to hide and close documents so i would love to get some input here or get in contact with someone.


import WebViewer from '@pdftron/webviewer';

let instance = null;

const initViewer = () => {
  WebViewer(
    {
      path: '/public/webviewer',
      useDownloader: true,
      initialDoc: "https://pdfobject.com/pdf/sample.pdf",
      backendType: 'asm'
    },
    document.getElementById('viewer')
  ).then(webviewerInstance => {
    instance = webviewerInstance;
  });
};

const cleanup = () => {
  if (!instance) return;

  try {
    instance.Core.documentViewer?.closeDocument();
    instance.UI.dispose();
    instance.Core.documentViewer?.dispose();

    const element = document.getElementById('viewer');
    if (element) {
      element.innerHTML = '';
    }

    instance = null;
  } catch (error) {
    console.error('Cleanup failed:', error);
  }
};

// Toggle button handler
document.getElementById('toggleBtn').addEventListener('click', () => {
  if (instance) {
    cleanup();
  } else {
    initViewer();
  }
});

With the added toggle button in index.html

<body style="margin:0">
  <button id="toggleBtn" style="position: fixed; z-index: 100; top: 10px; left: 10px;">
    Toggle Viewer
  </button>
  <div id='viewer' style='width: 100%; height: 100vh; margin: 0 auto;'></div>
</body>
1 Like
6

Hi there,

We have had memory issues that have been fixed in the past, is this on the latest version of WebViewer?

In addition, it looks like you are using the single-threaded solution, indicated by
backendType: 'asm'

Could you please try removing that line and let us know if the issue persists?

best regards,
Kevin

1 Like
7

(Unfortunately) this seems to fix the issue for the reproduction example. Now I’m back at the original problem and try to figure out whats going on… :roll_eyes:

1 Like
8

Hi there,

It may be possible that you are using an older version of Safari and thus web assembly threads may not work there.
Generally, the ‘ASM’ solution is a workaround for legacy browsers but with some downsides such as the memory leak.

Here’s a website that shows which browsers are compatible with web assembly threads:

best regards,
Kevin

1 Like
9

Yea unfortunately thats not the case.
The issue might not be related to Safari at all, yesterday I got the same in a Chromium based (Edge) Browser.

The viewer seems to get into a broken state when quickly unmounting/remounting the component. I checked via getCurrentPDFBackendType which returned 'ems' to reassure its not about ASM.

I leave some notes here in case you have something to say for these symptoms:

  • seemingly randomly after remounting the viewer a couple of times this occurs “[Error] Unhandled Promise Rejection: TypeError: Right hand side of instanceof is not an object
    b (webviewer-core.min.js:66:198)
    (anonymous function) (webviewer-core.min.js:64:492)
    r (webviewer-core.min.js:64:320)”
    (unfortunatly this error leads to unreadable stacktrace and minified gibber)

  • after this error subsequent unmount/mounts of the viewer are stuck at a loading progress of 0.5 forever and do not render a pdf without giving any error nor additional logging (debug logs turned on)

If that doesnt ring bell, I will try to create a reproduction.

1 Like
10

Thank you for your reply,

Unfortunately, the above error message seems like a generic error when failing to load resources. Could you please share a minimal runnable sample project to reproduce the issue?

Best regards,
Kevin

1 Like