PDF download automatically renamed to "document.pdf"

LeeMcLean

Actually, this force close behaviour happens with all downloads!

SirPavlova

I poked about in the Web Inspector & I think I found the issue. It's in the way the PDF file is loaded into PDF.js.

The built-in Firefox & WebKit implementations of PDF.js both recieve the actual PDF file as a byte array in the payload of a "message" event—there's no access to the HTTP headers. The filename in the Content-Disposition header needs to be passed to the PDFViewerApplication.open() function explicitly. Here's how it's done in each browser:

Firefox's implementation listens for the data in viewer.mjs (if you trace it back several steps, viewerApp = PDFViewerApplication). The event payload includes the Content-Disposition filename:

    
    window.addEventListener("message", function windowMessage(e) {
      // ...
      const args = e.data;
      // ...
      switch (args.pdfjsLoadAction) {
        // ...
        case "complete":
          // ...
          viewerApp.open({ // if you trace it back several steps, viewerApp == PDFViewerApplication
            data: args.data,
            filename: args.filename
          });

WebKit's implementation listens for the data in a side file they added called content-script.js, which calls PDFViewerApplication.open() in viewer.mjs. But content-script.js doesn't pass in the Content-Disposition filename. This is why some files are saving as ‘document.pdf’.

    open(data) {
        PDFViewerApplication.open({ data });
    },

    init() {
        // ...
        window.addEventListener("message", (event) => {
            const { message, data } = event.data;
            switch (message) {
                case "open-pdf":
                    this.open(data);

Orion uses WebKit's implementation, but with a couple of added lines that are clearly meant to fix it by adding the filename to the PDFViewerApplication (see Orion.app/Contents/Frameworks/WebCore.framework/Resources/pdfjs/extras/content-script.js):

    open(data) {
        PDFViewerApplication.open({ data });
        PDFViewerApplication.url = window.originalUrl;
        PDFViewerApplication._contentDispositionFilename = window.responseFilename;
    },

    init() {
        // ...
        window.addEventListener("message", (event) => {
            const { message, data } = event.data;
            switch (message) {
                case "open-pdf":
                    this.open(data);

But when I set breakpoints on that event listener in Orion & step through it all, window.originalUrl & window.responseFilename are undefined. Regression? Or maybe it was never fully implemented.

tl;dr: This is a WebKit problem & Orion has half-fixed it already.

LeeMcLean

SirPavlova If it is a Webkit problem, then:

1) Why does it work fine in Safari

2) As I reported, this issue doesn't just apply to PDFs - it also applies to files of any type (including images) downloaded from encrypted Facebook Messenger chats (not unencrypted chats though).

SirPavlova

LeeMcLean

I haven't looked into the Messenger problem you mentioned, but my hunch is that it's a separate issue & shouldn't have been merged into the PDFs-saving-as-“document.pdf” thread.

I was specifically posting about the PDFs-saving-as-“document.pdf” issue reported by Enzo & reproduced by tauon . What I reported about PDF.js is definitely the cause of that. It's just how PDF.js works. That issue doesn't occur in Safari because Safari doesn't use WebKit's PDF.js port to handle PDFs, it uses the operating system's PDF display stuff (PDFKit?).

bzgnyc

What is the status of a fix for this issue? Did SirPavlova's analysis bring us closer to a fix?

From the examples in:
https://orionfeedback.org/d/8598-pdf-viewer-is-changing-the-name-of-the-pdf/4

I notice that this issue is still present in Orion 1.0.4 with the example provided by JSiuDev in April 2025 though it is fixed for the examples I provided in 2024.

I still have the same issue with files shared with me on a regular basis that I unfortunately I can't post here for bug reproduction purposes -- they come from a repository hosted on AWS accessed from a link distributed in a personalized e-mail. Though Orion is my default browser on my laptop, I now copy and paste the links in that e-mail over to Brave to download those files with the correct filenames. Ideally, I could just let Orion open any link I trust in the e-mail without having to guess whether the filenames of any documents available for download will be preserved.

If it is not possible to fully fix this issue due to a WebKit and/or pdf.js issue, can someone highlight what is broken about them so the issue can be reported to them?

And/or create a workaround by offering Save from the context menu (i.e. right-click on the canvas) that follows all the RFC's for Content Disposition headers, URI encoding, etc to replace pdf.js's Download button. I see that Orion already offers Summarize Page and Translate with Kagi in that menu so it should be possible and presumably relatively simple compared to those to add an option to just save the file/PDF.

dino

bzgnyc We just went threw this issue again and fond the root cause finally. This is expected to be pushed in next release.

astruckm

cc @dino

bzgnyc

Hi not sure if "Next Release" means the RC released a few days ago but the release notes for it suggested this issue was supposed to be addressed in that release. However, I am still seeing an issue with the test case provided by JSiuDev in
April 2025: https://arxiv.org/pdf/2310.16818

[see details in https://orionfeedback.org/d/8598-pdf-viewer-is-changing-the-name-of-the-pdf/4]

Tested under both Sonoma/M1 and Catalina/Intel [Version 1.0.4 (143.3-rc), WebKit 619.1.11.111.2 Build date March 12, 2026]

dino

bzgnyc We shipped fix for this ticket with last RC, and also included one more relevant fix in new RC 143.4, so can you please test this again, as we are unable to reproduce this issue. And if it's still reproducible for you, can you please try with new clean profile and share a recorded video with us if we are missing something.

bzgnyc

dino Hi understand all these fixes should be there which is why I was excited to test.

Are you trying to reproduce on Sonoma or Sequoia+? And/or are all regression tests beng done for all Orion releases with each update? I am reproducing this easily on Orion/AS for Sonoma and Orion/Intel for Catalina. I reported in another thread some visual artifacts now showing up in Orion/AS for Monterey and Orion/Intel for Catalina that seem liked they would have been caught right away but have persited for several RCs.

Here is a quick video showing the issue on Orion/AS for Sonoma:

bzgnyc

dino Could there be a build/release version control issue? I notice that the files in the pdfjs/build folder all have dates that pre-date the last two RC:

total 6160
-rw-r--r--@ 1 xxx staff 1965279 Mar 4 19:14 pdf.worker.js
-rw-r--r--@ 1 xxx staff 636116 Mar 4 19:14 pdf.sandbox.js
-rw-r--r--@ 1 xxx staff 548401 Mar 4 19:14 pdf.js

dino

bzgnyc That's interesting, just tested that multiple time to reproduce this issue, and looks like there's some race condition which sometime fails to send filename to the PDF.js (depends how you open the PDF). We will add fix for that particular issue to next release for sure.

The issue is not related to macOS version or PDF.js version. Will share a dev build with you after applying that fix.

dino

bzgnyc can you please test this Dev build on your macOS 14 to check if this fixes that issue?
https://www.icloud.com/iclouddrive/07elD3FH0hIjZdTeDY3qc7KgA#Orion-14.0-143.4.0

Note: It's a dev/test build, so please don't replace your actual working RC copy, as this doesn't get future updates.

bzgnyc

dino Thanks, that seems to have done it!

Side note, wasn't able to download that file using Orion or Safari but Brave worked. Not sure what is going on with iCloud these days...

« Previous Page