1738129 - Context menu Save Link As... for a PDF opens the file instead of displaying a Save dialog with browser.download.improvements_to_download_panel true

Status: VERIFIED FIXED

(Firefox :: Downloads Panel, defect, P1)

Description

[B.J. Herbison]

Steps to reproduce:

1. In about:config set browser.download.improvements_to_download_panel to true. (The current default value in Nighty.)
2. In a search engine search for "dummy pdf file w3c" (without the quotes) to find an entry for https://www.w3.org/WAI/ER/tests/xhtml/testfiles/resources/pdf/dummy.pdf in the results.
3. Right click and select "Save Link As...".

Expected:
3) A Save dialog appears to select a location to save the file, and then the file is saved at that location.

Actual:
3) The file is opened immediately.

Setting browser.download.improvements_to_download_panel to false fixes the problem.

I'm seeing this with XFCE under Linux. Others have reported this type of behavior with Windows.

Comment 1

[:Gijs (he/him)]

Mass moving affected flag for download improvements issues found on Nightly to 96 (nightly from later today / tomorrow), as the download improvements pref will be disabled for 95 beta.

Comment 2

[:Gijs (he/him)]

The context menu code invokes the saveHelper. We pass true for aForceSave into DoContent, but somehow that doesn't enforce a save. The aForceSave param ends up at mForceSave on nsExternalAppHandler. Then it gets used in a few places. I suspect the issue is the condition here which looks like it checks if we're useHelperApp oruseSystemDefault (neither is the case) or checking for shouldAutomaticallyHandleInternally:

    if ((action == nsIMIMEInfo::useHelperApp ||
         action == nsIMIMEInfo::useSystemDefault ||
         shouldAutomaticallyHandleInternally) &&
        !alwaysAskWhereToSave) {
      rv = LaunchWithApplication(shouldAutomaticallyHandleInternally, nullptr);
    } else {
      rv = PromptForSaveDestination();
    }

We set shouldAutomaticallyHandleInternally to true based on the saved preferences for the (PDF) filetype, before we check mForceSave -- but don't override the value of shouldAutomaticallyHandleInternally, unlike what the comment suggests:

  // if we were told that we _must_ save to disk without asking, all the stuff
  // before this is irrelevant; override it
  if (mForceSave) {
    alwaysAsk = false;
    action = nsIMIMEInfo::saveToDisk;
  }

so we end up launching the file instead of saving to disk. We should add a test for this.

Comment 3

[Neil Deakin]

I can't reproduce this bug at all. The save dialog appears when I choose to save the link.

Comment 4

[Alice0775 White]

I can still reproduce the issue in Nightly96.0a1(20211106212323) Windows10 with new profile.

STR(comment#0)
Actual Results:
No file dialog open. The pdf file is downloaded to default download folder. And it open with Acrobat DC automatically.

Comment 5

[Romain Testard [:RT]]

I can reproduce on Windows. We seem trigger the default OS handler for pdf viewing as opposed to using the local content type association within Firefox.

Comment 6

[kpatenio]

I can reproduce this bug as well on MacOS Big Sur with a new profile using Nightly 96.0a1.

Result: opens PDF file immediately using my default app for PDF files.

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Note that this is not only happening for PDF files. I also see it when trying to download full log files from:

https://treeherder.mozilla.org/jobs?repo=mozilla-central&searchStr=wdh1%2Cdebug&revision=5e4047061e46c5cb86d1ef694bc206fc8f4e7d20&selectedTaskRun=Ji3wMEbNRt2La7lxXzGW-Q.0

The save dialog appears and a file name can be chosen. Then the download happens but the file is of size zero. Instead a second file gets created with a -1 prefix. Also immediately the registered default application gets opened.

Comment 8

[:Gijs (he/him)]

(In reply to Henrik Skupin (:whimboo) [⌚️UTC+1] from comment #7)

Note that this is not only happening for PDF files. I also see it when trying to download full log files from:

https://treeherder.mozilla.org/jobs?repo=mozilla-central&searchStr=wdh1%2Cdebug&revision=5e4047061e46c5cb86d1ef694bc206fc8f4e7d20&selectedTaskRun=Ji3wMEbNRt2La7lxXzGW-Q.0

The save dialog appears and a file name can be chosen. Then the download happens but the file is of size zero. Instead a second file gets created with a -1 prefix. Also immediately the registered default application gets opened.

Please file a separate bug to keep track of this, and provide more detailed STR because this doesn't reproduce on a clean profile. Let's keep this bug focused on what it got filed for, and if it so happens to fix the issue you're seeing we can dupe it over then, rather than trying to fix potentially different issues (because PDFs and "handle this internally" ie show PDF in Firefox - are pretty special, compared to other files) in the same bug.

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Filed my case with all the required details as bug 1741431.

Comment 10

[kpatenio]

Attachment: Bug 1738129 - fix Save Link As... for PDF files to show save dialog with downloads improvements pref enabled. r=gijs!,mtigley!

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/8b8063ff6d19
fix Save Link As... for PDF files to show save dialog with downloads improvements pref enabled. r=Gijs,mtigley

Comment 12

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/8b8063ff6d19

Comment 14

[Adrian Florinescu [:aflorinescu]]

The original steps from comment 0 are verified as part of Nightly 97 Remove Download Panel test run, with a follow-up issue bug 1747340 .