Hey, I am hosting a pdf on sanity and put it in a link on a webpage, recently I discovered that in safari it shows `Blocked plug-in` when clicking the link. This behavior...

Hey, I am hosting a pdf on sanity and put it in a link on a webpage, recently I discovered that in safari it shows

Blocked plug-in

{/*This was a test link where which works fine for me*/}
&lt;a href="<https://blog.bernina.com/de/wp-content/uploads/sites/2/2016/07/Schnittmuster-A-kleid.pdf>" target="_blank" rel="noopener"&gt;Schnittmuster A-Kleid&lt;/a&gt;
{/*This gives me the blocked plugin problem: */}
&lt;a href="<https://cdn.sanity.io/files/m29pqcus/staging/d103fbd4191583b07c87301e18e1afd954e62348.pdf>" target="_blank" rel="noopener"&gt;Aktuelle Verhaltensregeln / Hygienemaßnahmen.&lt;/a&gt;

Hi Sari, thanks for reporting this. It seems to be an issue with the Adobe plug-in and how plug-ins work in Safari in general, i.e. it’s not specific to your implementation, although that still doesn’t explain why it works with the other PDF in your code. Both links open the PDFs inside the browser, correct? And you’re not opening one of them in a separate tab but clicking both from within their own tab?

The latest versions of Safari use a new plug-in manager for enabling and disabling plug-ins on a global or per site basis. The Acrobat and Reader PDF viewer plug-ins are not trusted by default until you actively trust the plug-in globally, or for each website.

It seems be a common issue with some reports of it being resolved when people update Safari or Adobe Acrobat Reader, but other reports that it simply keeps showing the blocked plug-in warning.
I do see this in the console, which I’ll forward to the team just in case:

Refused to load <https://cdn.sanity.io/files/m29pqcus/staging/d103fbd4191583b07c87301e18e1afd954e62348.pdf> because it appears in neither the object-src directive nor the default-src directive of the Content Security Policy.

Shift-clicking the link to the PDF to open in new tab, or simply CMD+S to save it, should still work. It’s the preview that’s the issue in this case.

Also, you could try adding

?dl

Actually, there was a recent change in our content security policy that might have been a little too strict here. This was fixed just now, but just to make sure the CDN is not serving the old CSP headers, one of our devs recommends adding

?cache=break

<https://cdn.sanity.io/files/m29pqcus/staging/d103fbd4191583b07c87301e18e1afd954e62348.pdf?cache=break>

[Edited post above for extra context]