Safari on Big Sur freezes when embedding PDF file

[fdietz]

Hi all and thank you so much for your work!

I've been happily using PDFObject for embedding PDFs successfully for quite some time. Starting with Mac OS Big Sur though it seems Safari freezes when embedding PDFs. Instead of the PDF it only shows a gray Rectangle.

You basically then have to kill Safari Process to use it again.

Downloading PDFs works without problems, though.

It seems that others have similar problems: https://github.com/jupyterlab/jupyterlab/issues/9494, https://discussions.apple.com/thread/252247740

Looks like it is related to setting the type="application.pdf".

Has anyone else run into this problem?

Thanks in advance!

[pipwerks]

Thanks for reporting. That's an unfortunate bug. I'll look into it. In the meantime, you can probably skirt the issue by using the force iframe feature.

[theodore-s-beers]

I've been puzzling over the same issue. I thought I was going crazy.

In a regular Safari window, if I open one of my pages that's supposed to have an embedded PDF, sometimes it works, but often I just get the gray background. If I then refresh, everything will load correctly at once. Subsequent refreshes are also fine. Apparently having the PDF cached preempts the problem.

If I use a Safari private window, the PDF won't be cached, and I can repeatedly refresh the page, with the file sometimes being embedded and sometimes not.

It's almost like there's a race condition. But that impression could be way off base.

P.S. What's with Safari making multiple requests for a single PDF? I see one, or occasionally two requests for a certain byte range, and one request for the actual PDF. Is this what used to allow a kind of lazy-loading for large files? That was the one aspect of PDF embedding in Safari that I found superior to Chrome and Firefox. It doesn't seem to work anymore. I'm getting either the full embed, all at once when the file has been downloaded, or nothing at all. Still multiple requests, though…

[theodore-s-beers]

Also, I just tried setting forceIframe when the browser is detected as desktop Safari, and I can confirm that it works fine, at least in my case.

[fdietz]

Thank a lot for your quick answer :-)

I've tested with both the supportRedirect and the forceIframe flags. Both switch correctly to using an <iframe> when using Safari Desktop. So, there is no freeze/hang of the browser anymore. But, there's a new problem.

The first request works for me, the second request fails. The browser alert dialog shows an error message: "The file could not be opened because it is empty".

This seems due to caching. When I disable the Safari caching in the developer tools it works correctly.

In my case the URL first redirects to the final URL with the PDF. So, that could be the reason another reason. I'm just not sure if it's really connected to my problems. In all other major browsers and older Safari Desktop versions this all work fine.

Please, let me know if you need more information from me or if I should test other things. Hope we'll find a solution together. Thanks for your support!

[pipwerks]

I have finally upgraded to Big Sur (long story... had to wait for some app compatibility issues to be resolved) and have tested all the example PDF embeds. They all work fine expect the 302 redirect, which either fails to redirect or simply locks up. Not sure what the cause is, I will have to look into it.

@fdietz and @theodore-s-beers do you still encounter the freezing issue in Big Sur? Have the latest Safari updates resolved it for you?

[fdietz]

We can confirm that embedding described above works without freezing. But, since all our PDFs are behind redirects we completely disabled all PDF embedding for all Mac Desktop Safari users for the time being. We offer a download link instead.

Haven't found a fix or workaround yet!

Thanks for looking into this!

[theodore-s-beers]

Sorry I've been remiss in replying to this. The thing is, my colleagues and I haven't had any problems since I set forceIframe for desktop Safari. I'm not using redirects. I could try reverting that change to see if something has been fixed with <embed> in Safari, but I haven't had time.

[pipwerks]

PDFObject 2.2.6 is live and includes a patch for this issue. Thanks for reporting, please let me know if you run into any problems.

[mohan-triomics]

Still problem persists.

pdf object tag fails intermittently.

[pipwerks]

As of PDFObject 2.2.6, PDFObject will use an iframe for desktop Safari. If Safari continues to freeze up, I'm not sure there's anything else I can do. It is likely a Safari/macOS issue.

@mohan-triomics can you confirm you're using 2.2.6 or later, and that the embed is using an iframe?

[codeoflife]

Embedding a 45KB PDF 1.7 document (87KB base64 encoded) fails only in Safari due to this bug. The same test worked on Chrome, Firefox and Edge without issue. Symptom is a light grey box appearing instead of where the PDF should be rendered, there were no console errors via Safari's web-inspector. Version: Safari 16.4.1 (Desktop and iPhone) tested on 6/21/2023.

The workaround of using a iframe element instead of an embed/object element worked fine.

[theodore-s-beers]

workaround of using a iframe element

Honestly, it's not clear to me at this point why we should ever use <embed>.

[pipwerks]

@codeoflife the current version of PDFObject automatically uses iframe when Safari is detected. Are you saying it wasn't working until you manually specified iframe as the embed type?

@theodore-s-beers It's a historical artifact. PDFObject has been around for longer than some web browsers. When I first created PDFObject, the goal was to use the web standard <object> element (hence PDFObject), with <embed> as a fallback where needed, the same way SWFObject operated when embedding SWF files. The hope/assumption was that all browser vendors would eventually support the web standard <object>. Accessibility was also a motivating factor for avoiding <iframe> back in the day, as iframes were generally frowned upon by the A11Y community. But you're right, time has not been kind to either <object> or <embed>; they are not as widely supported as <iframe> in modern browsers, making <iframe> the safest bet, even for accessibility purposes.

[pipwerks]

As an aside, the PDFObject codebase has gone through big shifts over the years to stay aligned with current technology and best practices. When PDFObject was initially released, desktop browsers didn't natively support inline PDFs... PDFs could only be displayed in the browser if you installed PDF plugins like Acrobat and FoxIt. So, rolling with the punches, I will likely remove <embed> soon to reflect the current state of browser support and simplify the PDFObject codebase.

[theodore-s-beers]

not as widely supported as <iframe> in modern browsers

Yeah, iframes have come to be used in so many contexts that browser developers have more incentive to keep them working properly (Safari being the main culprit).

[codeoflife]

@pipwerks pipwerks commented Jun 22, 2023 @codeoflife the current version of PDFObject automatically uses iframe when Safari is detected. Are you saying it wasn't working until you manually specified iframe as the embed type?

Yes iFrame worked fine as a workaround on desktop Safari... however later I came across the additional issues on iOS (mobile) Safari mentioned well here https://discussions.apple.com/thread/250075244 That made me give up showing the PDF to the user and instead have them download it directly. That works fine.

[theodore-s-beers]

additional issues on iOS (mobile) Safari

That's a whole other can of worms. PDFObject is supposed to detect a mobile browser and fall back to showing a download link instead of trying to embed the PDF. Was it not doing that?

[codeoflife]

PDFObject is supposed to detect a mobile browser and fall back to showing a download link instead of trying to embed the PDF. Was it not doing that?

with an 'embed' element and base64 encoded PDF data src, it was not doing that.

[pipwerks]

@codeoflife My tests all function as expected. Can you provide an example that fails?

@codeoflife @theodore-s-beers @johnhunter I just uploaded a beta version of 2.3 which has some significant changes. I'd appreciate it if you can check it out and let me know if you encounter any issues. https://pdfobject.com/dev/ and https://github.com/pipwerks/PDFObject/tree/2.3-dev (changes are listed in the 2.3 branch readme). Thanks

[theodore-s-beers]

Actually, I do see a problem with the base64 example in iOS Safari. The script correctly detects the mobile browser and offers a fallback link, but the link doesn't work. Clicking it does nothing. This is the same in both the current and the "dev" version of PDFObject.

[pipwerks]

This is fixed in 2.3b. I have added a script that converts the base64 string to a downloadable file. Works well in my (limited) testing.