Bug: PDFjs download button has weird edge case where we still show 'what do you want to do with this file' dialog that is tested in browser_download_open_with_internal_handler.js
Status: RESOLVED
Priority: P3
Resolution: DUPLICATE
Created: 2022-01-19 20:19:47+00:00
Resolved: 2022-05-06 23:14:50+00:00

browser_download_open_with_internal_handler.js, among many many other things (maybe we should split that test...) opens a dummy PDF file from http, with PDF set to "always ask". Then it picks "open with Firefox". So the test downloads to the download folder (a subfolder of tmp, in the test) and displays it.

Then (after another bit of testing with a separate http load that's not related to this bug) we click the download button inside PDF.js. See [this link](https://searchfox.org/mozilla-central/rev/5d2b9e940ca09bd1cbc15aa681f69424cde8904c/uriloader/exthandler/tests/mochitest/browser_download_open_with_internal_handler.js#269-303) for code at time of writing, though I'm tweaking it in bug 1750042.

Now, after bug 1740135 I'd have expected that to open a "save as" dialog. But it doesn't, it opens another "what do you want to do with this file" dialog.

The reason seems to be that somehow we throw an exception of sorts (my JS debugger on nightly trunk appears semi-broken so I'm not sure what exactly) in [this code](https://searchfox.org/mozilla-central/rev/5d2b9e940ca09bd1cbc15aa681f69424cde8904c/toolkit/components/pdfjs/content/web/viewer.js#1069-1075) and then end up hitting the `downloadUrl` catch call. That ends us up with [this code](https://searchfox.org/mozilla-central/rev/5d2b9e940ca09bd1cbc15aa681f69424cde8904c/toolkit/components/pdfjs/content/web/viewer.js#13699-13704):

```js
  downloadUrl(url, filename) {
    FirefoxCom.request("download", {
      originalUrl: url,
      filename
    });
  }
```

This ends up talking to [the stream converter code](https://searchfox.org/mozilla-central/rev/5d2b9e940ca09bd1cbc15aa681f69424cde8904c/toolkit/components/pdfjs/content/PdfStreamConverter.jsm#342) which has this check:

```js
    // If the download was triggered from the ctrl/cmd+s or "Save Page As"
    // or the download button, launch the "Save As" dialog.
    const saveOnDownload = getBoolPref(
      "browser.download.improvements_to_download_panel",
      false
    );

    if (
      data.sourceEventType == "save" ||
      (saveOnDownload && data.sourceEventType == "download")
    ) {
      let actor = getActor(this.domWindow);
      actor.sendAsyncMessage("PDFJS:Parent:saveURL", {
        blobUrl,
        filename,
      });
      return;
    }
```

in other words, for saved PDFs (e.g. with form fields filled in) or downloaded PDFs if the download improvements pref is on, show a "save file" dialog. Otherwise, we fall through to the code below it, which shows the "what do you want to do with this file" dialog (unknownContentType.xhtml).

Now... the callsite above doesn't pass a `sourceEventType` at all. So neither of these conditions pass, and we end up falling through to the code below it anyway.

I think this isn't what we want? But I haven't thought about it too much. How user-relevant this is probably depends on what the condition is under which the viewer.js code throws an exception and falls back to `downloadUrl` - a quick test with a PDF I happened to have in my download folder locally  doesn't show this behaviour, it shows the "save file as.." dialog as expected. If I had to guess, there's something wrong with the dummy PDF with which we're testing and it throws off the code here.

Sam, thoughts?