1738916 - Firefox asks for a file location when "always ask me where to save files" is enabled, even if the file is configured always to open in an external app

Status: RESOLVED FIXED

(Firefox :: File Handling, enhancement, P2)

Description

[Michael]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:100.0) Gecko/20100101 Firefox/100.0

Steps to reproduce:

Attempts to download files from a URL.

Actual results:

All attempts to download files result in a Save As dialog. Attempted with the following file types with same results:

.csv
.xlsx
.docx
.pptx
.rtf
.zip
.jnlp

Expected results:

My expectation would be that I would be prompted for the desired action. Once a desired action was selected that action would be stored in "handlers.json" and displayed in Settings. But this is not happening. Save As is displayed in all cases.

I have attempted to manually update handlers.json and although this causes the file types to appear in Settings, the chosen action is still ignored and Save As is displayed.

This worked correctly prior to v95

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Firefox::File Handling' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Marco Bonardo [:mak]]

could you please Attach a log from about:support as a txt file?

Is this happening on multiple websites, or only specific ones? If the latter, can you provide an example link to the page to test?

Comment 3

[:Gijs (he/him)]

FWIW, I expect you have "always ask me where to save files" enabled. We now ask you this even for files you want to open. See this document explaining these changes on Nightly. It would be useful if you could confirm that this is the case.

Comment 4

[Michael]

(In reply to Marco Bonardo [:mak] from comment #2)

could you please Attach a log from about:support as a txt file?

Is this happening on multiple websites, or only specific ones? If the latter, can you provide an example link to the page to test?

If this is deemed the "new" behavior, I can say that as a user and a Product Manager in the software industry, this is a horrible design choice. This greatly degrades the user experience.

https://docs.google.com/document/d/1H0Uw7oNgATAN1Ji_MYj7loaY_H-GUmnkNKvwraeHWgQ/edit#

If I want/expect to automatically open a file type (e.g txt, zip, xlsx, docx, jnlp, etc) and my settings are configured as such then that is what I expect to happen. The file should be downloaded AUTOMATICALLY without user input to "tmp" in such a case and if possible deleted after automatically opened. Anything else is arguably a regression and/or significant degradation in behavior from prior versions. Note this "new" behavior is similar to what Chrome is doing and I will say again, this is a horrible design choice. As a result of this change in Chrome I (and many others have stopped using Chrome). Hopefully a similar fate will not be the case with FF.

For the following illustrations, an Excel spreadsheet was used from a random site as the downloadable file. Here is that URL:

https://www.excel-easy.com/examples/excel-files/percentage.xlsx

THE FOLLOWING ASSUMES THAT SETTINGS (APPLICATIONS) DOES NOT INCLUDE THE FILE TYPE

Actual behavior I am experiencing it is as follows:

1. Click a link that points to a "safe" or relatively safe file (e.g. xlsx)

2. A Save File dialog is presented. My expectation is I would get a dialog that asks what I want to do (e.g. Open, Save as, Open with...). However this does NOT happen. Saving the file is the only option presented.

3. If I choose to save the file, it is saved and nothing happens. Any automation is completely broken.

*** In this scenario, maybe I have no desire to "save" the file. I just want to view it once then move on to my next task. With this new behavior I now have to; click to download, save, view, then remember to delete. So what used to be a one click effort is now a four click effort. This is terribly inefficient.

THE FOLLOWING ASSUMES THAT SETTINGS (APPLICATIONS) INCLUDES THE FILE TYPE

Since I do not get prompted to add a handler nor does FF offer a valid editor to manually add a handler, in handlers.json I manually entered the following to handle Excel files:

"application/vnd.openxmlformats-officedocument.spreadsheetml.sheet":{"action":2,"extensions":["xlsx"],"handlers":[{"name":"EXCEL.EXE","path":"C:\Program Files (x86)\Microsoft Office\Office12\EXCEL.EXE"}]}

Actual behavior I am experiencing it is as follows:

1. Click a link that points to a "safe" or relatively safe file (e.g. xlsx)

2. A Save File dialog is presented. My expectation is that the file would be automatically downloaded and opened (since that is what is configured). However this does NOT happen. Saving first is required.

3. After the file has been viewed, it now becomes orphaned in the storage location chosen. This means every time a file is chosen to view another orphaned file will be created. For non-tech end users, they are unaware that saving to "tmp" or similar would help (although not solve) mitigate the orphaning impact this poor design choice exposes.

Again, the resulting behavior is incredibly inefficient and not at all user friendly.

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:Gijs, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 6

[:Gijs (he/him)]

This needs to be assessed by product/UX before we assign a severity.

Comment 7

[Andrei Purice]

Setting this enhancement to NEW in order for it to gain more visibility.

Comment 9

[:Gijs (he/him)]

OK, we had a discussion around this with some engineering and product folks. The main aim of our changes is to reduce user interruptions, and make downloading files more obvious and easy-to-use, especially for non-technical users. This particular, more expert usecase (have Firefox set to "always ask you where to save files", and have a particular file type set to always open with an external handler**) now adds an interruption that was not there before (asking you where to save the file, instead of just saving it and opening with an external application). That seems bad and contrary to our goals. It would seem preferable if we automatically saved the file, without asking for a location, and opened it immediately. As per the discussion in bug 1738574, we don't think using the temp folder for this is a good choice, even if it is what we do on release/beta today. So, to address this issue, for files set up to open automatically, we should save the files to the directory pre-selected by the user (defaults to the default downloads directory, but is user-configurable).

Then users could configure the default to directory A, and save any files they particularly want to save (rather than open) in some other location(s) B/C/D/... when they get prompted. If there are filetypes you sometimes want to open, and sometimes want to save, you can configure them to "always ask", and you should be able to get the "old" behaviour of being asked for an action rather than location, first.

This means that for people who want this flow (ie being asked where to save files, without being interrupted for files that always open with helper applications), they have a way of preserving it, while implementation should be reasonably straightforward.

** There is also the case where we don't have an action set for a filetype. We deliberately don't ask for a user action anymore by default; we'll save to disk by default, and for that we need to know where you want the file to be saved (that's what "always ask you where to save files" means), so we can't realistically change that behaviour without violating people's expectations.

Comment 10

[Michael]

(In reply to :Gijs (he/him) from comment #9)

OK, we had a discussion around this with some engineering and product folks. The main aim of our changes is to reduce user interruptions, and make downloading files more obvious and easy-to-use, especially for non-technical users. This particular, more expert usecase (have Firefox set to "always ask you where to save files", and have a particular file type set to always open with an external handler**) now adds an interruption that was not there before (asking you where to save the file, instead of just saving it and opening with an external application). That seems bad and contrary to our goals. It would seem preferable if we automatically saved the file, without asking for a location, and opened it immediately. As per the discussion in bug 1738574, we don't think using the temp folder for this is a good choice, even if it is what we do on release/beta today. So, to address this issue, for files set up to open automatically, we should save the files to the directory pre-selected by the user (defaults to the default downloads directory, but is user-configurable).

Then users could configure the default to directory A, and save any files they particularly want to save (rather than open) in some other location(s) B/C/D/... when they get prompted. If there are filetypes you sometimes want to open, and sometimes want to save, you can configure them to "always ask", and you should be able to get the "old" behaviour of being asked for an action rather than location, first.

This means that for people who want this flow (ie being asked where to save files, without being interrupted for files that always open with helper applications), they have a way of preserving it, while implementation should be reasonably straightforward.

** There is also the case where we don't have an action set for a filetype. We deliberately don't ask for a user action anymore by default; we'll save to disk by default, and for that we need to know where you want the file to be saved (that's what "always ask you where to save files" means), so we can't realistically change that behaviour without violating people's expectations.

Not using "tmp" as the download location is not a good idea. Imagine if a browser loaded a web page and stored all the resources that it used in the user's "Download" directory then abandoned them there. That's what is being considered for Firefox. Orphaning filed that the user doesn't want to keep will waste disk space (long term) as the user may not ever look in the directory where these files will be saved. The key points to this bug are:

1. Too many user interruptions are exposed when simply trying to open some content

2. Files expected to be "temporary" are now being stored permanently. They should be deleted after use or after some amount of time (like cache handling.

The user's "Download" directory (or whichever directory they set) should only be used for files the user intentionally has chosen to keep. It should not be used for files that are not planned (by the user) to be saved.

Comment 11

[:Gijs (he/him)]

(In reply to Michael from comment #10)

1. Too many user interruptions are exposed when simply trying to open some content

We're fixing this, as outlined in comment 9.

2. Files expected to be "temporary" are now being stored permanently. They should be deleted after use or after some amount of time (like cache handling.

This isn't really what this bug is about - the decision not to use tmp was extensively discussed in bug 1738574, and we're not revisiting it here.

Fundamentally, having always-opened files be ephemeral (deleted after use) is a user dataloss risk (x-ref also points made in bug 453455). We can't have it both ways, and we've decided to err on the side of potentially storing too much, rather than potentially storing too little. It's easy for users to delete files they don't care about; it's harder for them to get back files that have been deleted from disk.

As noted in bug 1738574, we're not going to do autodeletion for these files in Firefox itself (outside of private browsing mode). We'll investigate exposing relevant information to add-ons so they could clean or autodelete files that were "only" auto-opened; a purely time-based method could already be implemented in an add-on today without further APIs added on the Firefox side.

Comment 12

[Sam Foster [:sfoster] (he/him)]

Note to self, this boils down to updating this logic in nsExternalHelperAppService.cpp

    bool alwaysAskWhereToSave =
        !Preferences::GetBool("browser.download.useDownloadDir") &&
        StaticPrefs::browser_download_improvements_to_download_panel();

Comment 13

[Sam Foster [:sfoster] (he/him)]

Attachment: Bug 1738916 - when users want asking where to save files, do not ask for files automatically opened with helper applications, r?mhowell

• Tests are TODO. Seems like there should be failures in browser_shows_where_to_save_dialog.js with these changes, but its passing locally for me. So either that's not testing what I think it is, it was a false positive all along, or I'm doing something wrong...

Comment 14

[:Gijs (he/him)]

Sam is out, gonna take a stab at this.

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/00c6ddc131a4
when users want asking where to save files, do not ask for files automatically opened with helper applications, r=mhowell

Comment 16

[Atila Butkovits]

Backed out for causing failures at browser_default_audio_filename.js .

Backout link: https://hg.mozilla.org/integration/autoland/rev/f9957d0ccebbb61d0cccb257e845ceeb86b52c88

Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&selectedTaskRun=N_-3bEhjQyCMEQk1VZ3BJw.0&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel&revision=00c6ddc131a42a52566364688b78b716fd45865c

Failure log: https://treeherder.mozilla.org/logviewer?job_id=362009099&repo=autoland&lineNumber=3769
https://treeherder.mozilla.org/logviewer?job_id=362009174&repo=autoland&lineNumber=43492

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/98d579a676fa
when users want asking where to save files, do not ask for files automatically opened with helper applications, r=mhowell

Comment 18

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/98d579a676fa

Comment 19

[lrdix]

(In reply to :Gijs (he/him) from comment #11)

It's easy for users to delete files they don't care about; it's harder for them to get back files that have been deleted from disk.

I am not so sure about this. In the end, we are talking about files we find online. So, if we lose a file, most probably we lose it a short time after downloading it. In most cases, we then can download it again by using the download panel. Easy, and rare.

On the other hand, when everything goes right, which is the usual case, we have to delete files. Time-consuming, nerve-wracking, and that very likely many times per day.

And the reason is: Someone decided to stop using /tmp, because they “think browsers should err on the side of making downloaded files easily accessible, and leaving the choice of whether they get deleted to the user. The previous location (the Temp directory) was not discoverable for end-users, and led to data loss when the application in which the file was opened didn’t provide a way of saving a separate copy.” (https://docs.google.com/document/d/1H0Uw7oNgATAN1Ji_MYj7loaY_H-GUmnkNKvwraeHWgQ)

I still don’t get where that idea, that a user could be trying to discover a file they expect not to be anywhere around on their machine, is coming from. An application that doesn’t provide a way of saving a file is very rare, I dare to claim. Applications that allow to be started by opening their type of files usually provide that. Apps that don’t provide that sort of dialog save data immediately when it is being changed, as far as I know. I have seen such software, and it doesn’t use files you would download or directly open out of a browser (ITT software). I am afraid you are, benevolently as it is, stuck in the fear of a problem that is way more remote from every-day reality than you think.

Comment 20

[Michael]

I realize this issue has been flagged as closed, but either there is a regression or the issue was not fixed correctly. Now (v100.0a1), regardless of what Save setting you use the user is always prompted to "save" the file somewhere. Nearly all file types fall into this situation. It seems that only web formats will just open (e.g. html, etc). I have tried opening Excel (xlsx, docx, jnlp, etc) and all prompt to save and do not automatically open.

Also, user is never prompted to choose an app to Open the file with when not recognized.

This is terrible behavior and a huge step backward.

Comment 21

[Nazar Mokrynskyi]

I agree. New behavior is actively annoying, I waste time because of it every day. I wish there was an option to just revert downloads mechanism to old behavior so I don't have to do a bunch of clicks for what was previously one and don't have random temporary files in my downloads directory all the time that I need to go and manually clean up later.

Comment 22

[:Gijs (he/him)]

(In reply to Michael from comment #20)

I realize this issue has been flagged as closed, but either there is a regression or the issue was not fixed correctly. Now (v100.0a1), regardless of what Save setting you use the user is always prompted to "save" the file somewhere. Nearly all file types fall into this situation. It seems that only web formats will just open (e.g. html, etc). I have tried opening Excel (xlsx, docx, jnlp, etc) and all prompt to save and do not automatically open.

If you haven't yet, you can use the context menu on Excel/Word files to always open those files, and that should work (ie not prompt for a location, and open automatically). If it doesn't, please file a new bug with clear steps to reproduce. This bug is talking about whether we prompt for a location before automatically opening the file, which isn't the same thing you're saying (you appear to indicate there is a prompt for a location, after which the file doesn't open at all).