# Regressão - Downloads de PDF iniciados ao clicar (deveriam abrir em nova aba)

**URL:** https://meta.discourse.org/t/regression-pdfs-download-initiated-on-click-should-be-open-in-new-tab/404910
**Category:** Bug
**Tags:** pdf-previews, fixed
**Created:** [10 Junho , 2026 03:14 UTC](https://meta.discourse.org/t/regression-pdfs-download-initiated-on-click-should-be-open-in-new-tab/404910 "2026-06-10T03:14:15Z")
**Posts on this page:** 5
**Page:** 1

<div class="post-metadata">

### Author: ![nathank](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/nathank/32/290039_2.png) [@nathank](https://meta.discourse.org/u/nathank)
#### Post date: [10 Junho , 2026 03:14 UTC](https://meta.discourse.org/t/regression-pdfs-download-initiated-on-click-should-be-open-in-new-tab/404910/1 "2026-06-10T03:14:15Z")

</div>

Estou percebendo que clicar no link do PDF quando a pré-visualização do PDF está ativa atualmente tenta baixar o PDF (indesejado) em vez de abri-lo em uma nova aba.

Isso ocorre em um ambiente de auto-hospedagem simples (único contêiner, sem CDN, sem S3).

Tudo isso foi abordado anteriormente aqui:

> [@david](#):
>
> Isso deve ter sido resolvido desde [SECURITY: Download allowlist for uploaded files · discourse/discourse@9c0642a · GitHub](https://github.com/discourse/discourse/commit/9c0642a2e79040a140b99601296cb10cf425eb9f)
> 
> Agora temos uma lógica centralizada para determinar quais arquivos devem ser exibidos „inline“. Isso significa que os PDFs são exibidos consistentemente de forma inline, e alguns tipos de arquivo menos seguros são servidos consistentemente como downloads. Essas alterações devem funcionar em todos os tipos de armazenamento de upload (local e S3, com ou sem CDNs).

---

<div class="post-metadata">

### Author: ![zogstrip](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/zogstrip/32/512781_2.png) [@zogstrip](https://meta.discourse.org/u/zogstrip)
#### Post date: [10 Junho , 2026 14:10 UTC](https://meta.discourse.org/t/regression-pdfs-download-initiated-on-click-should-be-open-in-new-tab/404910/3 "2026-06-10T14:10:34Z")

</div>

Estávamos sendo inconsistentes com o tipo `display` dependendo de você estar usando ou não o S3. Isso deve ser corrigido por

> <https://github.com/discourse/discourse/pull/40739>
>
> Inline-safe uploads (images, PDFs, audio and video) served from the local
> file s…tore were sent with \`Content-Disposition: attachment\`, so clicking a
> PDF link downloaded the file instead of opening it in the browser. This was
> inconsistent with the S3 store, which already serves these files inline, and
> it left simple self-hosted (single-container, no S3/CDN) sites unable to open
> PDFs inline.
> 
> \`UploadsController#send\_file\_local\_upload\` only set the disposition to
> \`attachment\` for unsafe types, and to \`inline\` when \`?inline=1\` was passed,
> leaving it unset otherwise. Rails' \`send\_file\` defaults an unset disposition
> to \`attachment\`, so inline-safe files fell through to a download.
> 
> Inline-safe files are now served with \`Content-Disposition: inline\` by
> default, mirroring the S3 store, while unsafe types (HTML, SVG, XML, ...) and
> explicit downloads (\`?dl=1\`) keep the \`attachment\` disposition. The redundant
> \`params\[:inline\]\` branch is removed, since inline-safe files are now inline by
> default.
> 
> The \`Content-Security-Policy: sandbox;\` header stays on \*\*every\*\* response as
> defense-in-depth: if the \`is\_inline\_safe?\` allowlist is ever wrong, the
> sandbox forces an opaque origin and disables script execution so a
> misclassified file cannot run as a document in our origin. It does not
> interfere with inline viewing — \`sandbox\` sandboxes scripts \*inside\* the
> served file, not the browser's native rendering of it. Chrome's built-in PDF
> viewer and Firefox's pdf.js both render sandboxed PDFs identically to
> unsandboxed ones, and images/audio/video decode natively regardless.
> 
> A spec locks the allowlist invariant by asserting no inline-safe extension
> maps to a script-capable content type, so re-adding something like SVG or XML
> to the allowlist fails CI instead of becoming a stored XSS.

(cc @david)

O fato de clicar em um arquivo abrir _automaticamente_ em outra aba é mais uma questão de #product.

---

<div class="post-metadata">

### Author: ![system](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/system/32/443519_2.png) [@system](https://meta.discourse.org/u/system)
#### Post date: [23 Junho , 2026 11:23 UTC](https://meta.discourse.org/t/regression-pdfs-download-initiated-on-click-should-be-open-in-new-tab/404910/4 "2026-06-23T11:23:04Z")

</div>



---

<div class="post-metadata">

### Author: ![david](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/david/32/157490_2.png) [@david](https://meta.discourse.org/u/david)
#### Post date: [14 Julho , 2026 17:14 UTC](https://meta.discourse.org/t/regression-pdfs-download-initiated-on-click-should-be-open-in-new-tab/404910/5 "2026-07-14T17:14:32Z")

</div>

A correção ainda não foi mesclada

---

<div class="post-metadata">

### Author: ![system](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/system/32/443519_2.png) [@system](https://meta.discourse.org/u/system)
#### Post date: [14 Julho , 2026 17:22 UTC](https://meta.discourse.org/t/regression-pdfs-download-initiated-on-click-should-be-open-in-new-tab/404910/6 "2026-07-14T17:22:06Z")

</div>


