1790641 - Downloaded files that are automatically opened are deleted on exit of private window

Status: VERIFIED FIXED

(Firefox :: Downloads Panel, task, P2)

Description

[rcandres]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:104.0) Gecko/20100101 Firefox/104.0

Steps to reproduce:

In a private window, I downloaded a PDF file that auto-opened in Firefox (the URL in the pdf viewer clearly showed it as in my download folder, not that it loaded from a URL).

Actual results:

On closing the private window, the downloaded file deleted itself from my drive. I'm guessing it marked itself as a temporary file despite being downloaded and not viewed, but if I download a file it should be more clear whether or not it is temporary.

Expected results:

I was expecting the file to stay around, much like any other file I download.

I'm not sure if this is a bug or an intended feature I've been on the wrong end of, but I've lost a good bit of data this way by accident.

Is this an interaction with private browsing, a normal feature of downloaded files that auto-open, or something else?

If this is an intended behavior, can these files be marked as "will be deleted on exit" or similar in the download manager, ideally with a way to cancel the behavior?

Also, what even causes this? Some PDFs view normally in Firefox without downloading at all, some download to my drive, and some download with the auto-open set to on (which I'm guessing also treats them as temporary to delete on exit). Why are there different behaviors?

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[rcandres]

Updated information:

Files that download that auto-open are deleted when the window closes.
Files that do not auto-open OR are stopped from auto-opening on completing* while still downloading are not deleted when the window closes.

*(note: I have not tested the behavior of files that are manually told to open on completing the download)

There is no visual distinction between these behaviors once the file has completed downloading, other than the presence of an open PDF viewer (if it is still open). Both show up as completed downloads with a "show in folder" button.

Comment 3

[wingwing0x]

I just faced this issue on firefox 106.0.2 but on Windows 11. Just like rcandres said above, when a file that auto-opens in firefox upon downloading (like a pdf file) is downloaded in a private window and then the window is closed, the file is also deleted.

Comment 4

[wingwing0x]

Just want to add that the file is deleted regardless of whether it is open or not in firefox at the time when the private window is closed. Also I think the bug should be under Networking: File since its not limited to linux (or gtk).

Comment 5

[Valentin Gosu [:valentin] (he/him)]

In a private window, I downloaded a PDF file that auto-opened in Firefox (the URL in the pdf viewer clearly showed it as in my download folder, not that it loaded from a URL).

Could you explain how you did that? I can't find a way to open a PDF that also downloads it.
Could you link to the page you used?

In any case, Networking doesn't really manage downloads. Moving to Firefox::Downloads Panel

Comment 6

[Peter Magyari (Desktop QA)]

wingwing0x, could you attach a link to the pdf file you were able to reproduce this issue on?

Thanks!

Comment 7

[rcandres]

I'm sorry, but it was an institutional-type document and I no longer have the link. This one seems to be working, though - I got a sample PDF (which downloaded and opened automatically), but it disappeared when I closed the incognito browser: https://smallpdf.com/blog/sample-pdf

Comment 8

[Valentin Gosu [:valentin] (he/him)]

Thanks, I can confirm the link can reproduce this.

1. Open https://smallpdf.com/blog/sample-pdf in Private Browsing
2. Accept All
3. Download Sample PDF
4. Click Download button (arrow down)
5. Close private window.
6. Downloaded file is deleted

Comment 9

[duckzill0r]

I can confirm this behavior on 106.0.3 (Win10).

Automatically downloaded files (like pdfs) are removed from "Downloads" folder after closing the Private Browsing session.
I would argue that this bug can have severe impact if files are deleted, that the user never would expect to be deleted (like files stored in "Downloads" folder).

Comment 11

[:Gijs (he/him)]

Downloads in private windows that auto-opened have been deleted when private browsing stopped pretty much as long as private browsing has existed.

We made a decision to keep it that way when we changed the default location for these files from tmp to the default downloads folder, because worsening the privacy guarantees of private browsing by default seemed like a bad idea. Certainly there were also enough people complaining after the fact in bug 1738574 about "clutter" and wanting the downloads to disappear (even in non-private mode, on Windows/Linux, this had been the default, though on browser shutdown) that I figured this was the right decision.

It's not clear to me what prompted several people to now feel this behaviour is wrong - bug 191239 didn't have duplicates for a very long time - and if it just feels wrong for pdfs shown in Firefox or for everything. I'd be curious to hear more details about this from the people reporting / commenting on this. Was there a reddit post or similar, perhaps? (I found this one but it's old)

Either way any change here is a product decision as this is currently deliberate behaviour, so setting pm-triage-needed.

Comment 12

[duckzill0r]

I just discovered this bug while looking through bugzilla and then noticed that I had experienced this behavior some time ago when a file I thought is safe got deleted (luckily I could redownload the file). But I am not a power user of the Private Browsing mode. I probably use ot only once a month, if ever. So I never thought too much about creating an issue.

Anyway, the confusion for me comes from the fact, that Firefox changed the download behavior from version 98 (I guess?) to "Automatic Download" while previously it was "always ask".
So maybe I confused automatic downloads with "automatic saves". Because previously I had selected a location to save files, even from Private Browsing, and I think they would be save.
So what I expected is, that if it's now automatically saved - the behavior is the same as if I had selected my Downloads folder manually - which is obviously not the case.

Comment 13

[:Gijs (he/him)]

(In reply to duckzill0r from comment #12)

Anyway, the confusion for me comes from the fact, that Firefox changed the download behavior from version 98 (I guess?) to "Automatic Download" while previously it was "always ask".
So maybe I confused automatic downloads with "automatic saves". Because previously I had selected a location to save files, even from Private Browsing, and I think they would be save.
So what I expected is, that if it's now automatically saved - the behavior is the same as if I had selected my Downloads folder manually - which is obviously not the case.

The behaviour is the same unless you automatically open the files. This is the case by default for PDFs, and webp/avif, but not other files. Automatically saving (and not opening) isn't affected and those files aren't deleted. The steps in comment #8 might be a little confusing to read if you don't actually try them - when clicking the "download" button in step 4 that's a button on the website in question, which sends Firefox a PDF that is saved to disk and automatically opened in a new tab (sourced from local disk). That is what trips the deletion mechanism.

Comment 14

[Simon Friedberger [:simonf]]

I don't have all the bug numbers handy but my view is:

From a UX perspective it doesn't make a difference to people if they are opening
a) a website
b) a PDF on a website
c) a PDF which wants to be downloaded on a website

However, c) behaves differently.

Storing to /tmp and deleting afterwards is sensible because it mimicks the behavior of a) and b).
Storing to ~/Downloads is strange because now files which the user didn't want on their computer clutter their Download folder. If we start deleting files from there, like in PBM, it's extra odd because people who actually want the file don't think about storing it anymore because the URL bar says it's already there. (:Gijs, I think that's the answer to your question why these issues are now popping up. People are getting used to the files being there.)

Private Browsing:
For private browsing, it's a bit more tricky than storing to /tmp. Ideally it would just live in memory with the rest of the private browsing session because if somebody looks at some distasteful PDF they probably don't want other users to see those PDFs in /tmp.
And this problem might actually be worse for ~/Downloads because the user might have deliberately set lax access rights there.

External Applications:
There is a case d) a file is automatically opened with an external application
In this case some kind of file is necessary to be passed to the external application. That file does however need to be thoroughly write protected so that nobody makes changes to it and gets confused when it is later deleted.

Comment 15

[:Gijs (he/him)]

(In reply to Simon Friedberger (:simonf) from comment #14)

From a UX perspective it doesn't make a difference to people if they are opening
a) a website
b) a PDF on a website
c) a PDF which wants to be downloaded on a website

This just isn't generally true, even if it is for you. See e.g. bug 1756980 and everything linked to it, bug 1772569, a number of other bugs we wontfixed that are still unhappy because we show the PDF at all in case (c) and who just want it downloaded, not opened, but only in case (c).

I get that it's what you think, but extrapolating from that experience unfortunately isn't always a good predictor.

Anyway, if this is what you want, you can get it - just flip browser.download.open_pdf_attachments_inline to true.

Storing to /tmp and deleting afterwards is sensible because it mimicks the behavior of a) and b).
Storing to ~/Downloads is strange because now files which the user didn't want on their computer clutter their Download folder.

This is covered in bug 1738574. I think "files which the user didn't want" is making a lot of assumptions that (as per that bug and the ones I linked earlier) don't necessarily hold. I would like not to relitigate all of that here.

If we start deleting files from there, like in PBM, it's extra odd because people who actually want the file don't think about storing it anymore because the URL bar says it's already there. (:Gijs, I think that's the answer to your question why these issues are now popping up. People are getting used to the files being there.)

Could people just get used to them still being deleted in private browsing mode? :-)

Private Browsing:
For private browsing, it's a bit more tricky than storing to /tmp. Ideally it would just live in memory with the rest of the private browsing session because if somebody looks at some distasteful PDF they probably don't want other users to see those PDFs in /tmp.

As noted above, we've made the decision in response to user feedback that this isn't viable, so now it's treated the same as "always open in [external app]".

And this problem might actually be worse for ~/Downloads because the user might have deliberately set lax access rights there.

I mean, the what-ifs here I think aren't really helpful. "Don't do that" would be sensible advice in this case, not least because an attacker could probably overwrite executables you're in the process of downloading and think are benign, etc.

External Applications:
There is a case d) a file is automatically opened with an external application
In this case some kind of file is necessary to be passed to the external application. That file does however need to be thoroughly write protected so that nobody makes changes to it and gets confused when it is later deleted.

What does "thoroughly write protected" mean here? We have to write to the file, we're downloading it... do you just mean you want Firefox to set the file as read-only on Windows, and 0o400 on linux/mac, once we finish downloading? Do we know if that's actually safe, ie how many apps will break if they can read but not write to the file (e.g. to update file-format specific "last opened" timestamps or w/e) ?

Comment 16

[:Gijs (he/him)]

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

What does "thoroughly write protected" mean here? We have to write to the file, we're downloading it... do you just mean you want Firefox to set the file as read-only on Windows, and 0o400 on linux/mac, once we finish downloading? Do we know if that's actually safe, ie how many apps will break if they can read but not write to the file (e.g. to update file-format specific "last opened" timestamps or w/e) ?

(Oh, and also: is this not already the case? We certainly have code that assumes it is.)

Comment 17

[Simon Friedberger [:simonf]]

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

(In reply to Simon Friedberger (:simonf) from comment #14)

From a UX perspective it doesn't make a difference to people if they are opening
a) a website
b) a PDF on a website
c) a PDF which wants to be downloaded on a website

This just isn't generally true, even if it is for you. See e.g. bug 1756980 and everything linked to it, bug 1772569, a number of other bugs we wontfixed that are still unhappy because we show the PDF at all in case (c) and who just want it downloaded, not opened, but only in case (c).

I'm not saying people don't want something else other than "open PDF". I am saying IF we open it, it looks the same as the other cases. Which is why people are complaining about the "clutter". They didn't expect a download.

If we start deleting files from there, like in PBM, it's extra odd because people who actually want the file don't think about storing it anymore because the URL bar says it's already there. (:Gijs, I think that's the answer to your question why these issues are now popping up. People are getting used to the files being there.)

Could people just get used to them still being deleted in private browsing mode? :-)

I don't think it's appropriate to delete files from ~Downloads. /tmp is fine but ~Downloads is a regular folder and users don't expect their files to get deleted. Plus, if we start deleting files from ~Downloads a big chunk for the motivation to move from /tmp to ~Downloads applies again.

Private Browsing:
For private browsing, it's a bit more tricky than storing to /tmp. Ideally it would just live in memory with the rest of the private browsing session because if somebody looks at some distasteful PDF they probably don't want other users to see those PDFs in /tmp.

As noted above, we've made the decision in response to user feedback that this isn't viable, so now it's treated the same as "always open in [external app]".

I think the clearest solution here would be to just not open in external app but always be explicit about the download. But I doubt people would appreciate the difference in behavior from regular Firefox.

And this problem might actually be worse for ~/Downloads because the user might have deliberately set lax access rights there.

I mean, the what-ifs here I think aren't really helpful. "Don't do that" would be sensible advice in this case, not least because an attacker could probably overwrite executables you're in the process of downloading and think are benign, etc.

True, but as long as the applications which need access to the files can get them we could even create a new /fxtmp or similar with whatever strictest permissions are possible.

External Applications:
There is a case d) a file is automatically opened with an external application
In this case some kind of file is necessary to be passed to the external application. That file does however need to be thoroughly write protected so that nobody makes changes to it and gets confused when it is later deleted.

What does "thoroughly write protected" mean here? We have to write to the file, we're downloading it... do you just mean you want Firefox to set the file as read-only on Windows, and 0o400 on linux/mac, once we finish downloading? Do we know if that's actually safe, ie how many apps will break if they can read but not write to the file (e.g. to update file-format specific "last opened" timestamps or w/e) ?

The point is that the user should not be able to make changes to a file which will be deleted.
And honestly, if an external application has a file which cannot be saved in a different location because of file specific restrictions and still lets the user make changes to write protected files (which he then clearly cannot save) I think that's a bug in that application.

Comment 18

[duckzill0r]

I totally agree with simonf.

The problem is, that from the user's perspective they (and that applies to me too) it doesn't matter, what exactly Firefox in the Background does. But having 3 cases that nearly look the same, but one of the 3 cases behaving differently is just confusing.

There are a lot of sites requesting PDFs to be downloaded and usually I am just straight away deleting all the PDF-clutter in my Downloads folder... and probably many users do that. So it's really rare cases when I am opening a File in PBM and then need it afterwards - but if I needed it, and it got automatically deleted while it was saved to "Downloads" and not "temp", this is weird behavior - because to Downloads we usually store saved/Downloaded files. And not files that are there "just for viewing". Even though Firefox "views" all PDFs downloaded there automatically.

A sensible default would probably to revive the download dialogue for PBM, to clarify for the user, that he needs to download this file, because the site performs a download task. And then keep this file, because the user has been advised it's a download and he needs to take care of that - but of course there are still other problems.

Comment 19

[rcandres]

I can clarify why this is a problem for me. See, in most cases when you view anything in the browser, it's memory-resident. About 75% of PDFs are as well - the address bar shows them as located at a URL, rather than downloaded. If I save a PDF, I expect it to be saved in my downloads folder (or wherever I've configured that to be, since I use an external drive custom folder destination). But some PDFs just download when you click on them, which may or may not lead to them also being auto-opening*. Again, if I've saved a PDF, or downloaded one by accident because the site somehow does that automatically, I expect it to be saved or downloaded, even if I didn't intend to do that. If I save one, it's in Downloads and I can view it in the browser by clicking it in the drawer. It's safe for later. I'm not about to go "saving" an opened PDF that's in my downloads folder again, because I expect it to remain there.

*(if anyone can clarify how that gets set, I'd love to know; I dabble in web dev and this would be helpful, or just for duplicating this sort of behavior for testing.)

But this behavior breaks that expectation. If it auto-opens, it's seemingly "safely" downloaded and I can view it, too, but it is (actually) silently deleted later. This means that important documents I downloaded sometimes get retroactively deleted from my system when I expected them to be safe. I can't even tell when this happens or know what got deleted afterward, so this is highly concerning to me.

(I'm not actually sure if this is only in private browsing or if that's a general behavior even in normal browsing, which would be even worse. But I noticed it in private browsing.)

To my knowledge, only PDFs do this (if I download a zip file of code from a course, say, that gets downloaded and stays around). If I open an image in a new tab to zoom in on some distant text, it's not downloaded but I expect that. But if I'm in private browsing so I can make sure the thing logs me out or doesn't leave tracking cookies, sometimes my invoices disappear!?

Comment 20

[rcandres]

(In reply to Simon Friedberger (:simonf) from comment #14)

I don't have all the bug numbers handy but my view is:

From a UX perspective it doesn't make a difference to people if they are opening
a) a website
b) a PDF on a website
c) a PDF which wants to be downloaded on a website

However, c) behaves differently.

Yes, that's exactly the issue. C leads to download folder clutter, on rare occasions, but most PDFs today (in my personal experience) are either loaded "at a URL" from a website or intentionally downloaded. You do still get the rare search result that's a PDF that downloads, but usually if I download a PDF, I meant to do that, and the button was labeled "download." This is all fine.

But sometimes, rarely, you have magic happen and the site decides that the file should also be opened too, despite being an intentional download.
I actually find that annoying, since this ironically tends to happen when I've clicked an actual download button and it opens as well as downloading. And then, the part I wanted (the download, not the allegedly "helpful" tab clutter that just stole focus) disappears! Since this happens when I'm done with whatever I was doing and close the browser, it's not even temporally-coupled with my task, so it's impossible to determine what went missing by this point.

Comment 21

[rcandres]

Addition:
This might not really be "just" a PDF issue, for all that it seemed like one on the surface. It's that there exists something other than "open in browser" or "download" that likes to masquerade as the latter. If it can't open in browser, I'd expect it to download and stay there. If I intentionally save it from pdf.js (or other in-browser viewers like audio/video), I expect it to download and stay there. In-page download buttons might do either of those at random because web development is hard :D (but, if successfully downloaded, stay there).

The existence of a download that isn't saved is unintuitive. In a perfect world, I would expect files to either open in-browser or download (and then possibly open - and we also have the button in the drawer to do that - but never self-delete). The existence of a second type of download has historically caused any number of other issues like users editing temporary files that delete themselves later, downloaded files having the wrong permissions, or now, "downloaded" files that delete themselves later.

If we need to maintain the behavior of a downloaded file that (for whatever reason) is also flagged as automatically viewed, can we display a flag/warning/toggle in the downloads drawer so that the user is informed that it will disappear? Or not show it in the drawer/downloads progress icon, but with some other indicator (perhaps a new tab with full-page progress bar saying 'opening')? (Or just keep it around in the downloads folder since it was, after all, downloaded?)

Normally, if it's in the drawer, it's saved and safe. If it auto-opens, it still shows up in that drawer and is still in the Downloads folder. Both behave exactly like a non-temporary file. If it's to be treated as a temporary file, I think the name should be mangled to obviously contain "temp" and other signs that it's machine-generated, while the downloads drawer should warn that it will be deleted later.

If there's a toggle in the drawer, moving it to "I actually meant to save that" will rename the file to its expected name and remove the warning in the drawer.

Really, though, I'd rather it just download and remove the ability to auto-delete (or at least disable the feature via setting/config?). We now have the option to delete the file right from the download drawer if we don't want to keep it around afterwards.

Comment 22

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

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

For more information, please visit auto_nag documentation.

Comment 25

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

The following field has been copied from a duplicate bug:

Field	Value	Source
Regressed by	bug 1772569	bug 1278811

For more information, please visit auto_nag documentation.

Comment 26

[Masatoshi Kimura [:emk]]

Not a regression per comment #13. Reverting the change. But... (see below)

Comment 27

[Masatoshi Kimura [:emk]]

I want to automatically save the file when a element has a download attribute and automatically open the file when download attribute does not exist. Currently it is not possible for PDF files. If I choose "Open in Firefox", PDF files will open in both cases. If I choose "Save File", PDF files will be saved in both cases.

This is possible for other file types such as .txt. I made a testcase. When you click "View", the text file will open in Firefox. When you click "Download", the text file will be saved. This behavior is not possible for PDF.

Chrome works as expected for both .txt and PDF.

Note that, although I made this testcase, I want this behavior as a user. Non-default setting (even with an about:config pref) is OK to me.

Comment 28

[:Gijs (he/him)]

(In reply to Masatoshi Kimura [:emk] from comment #27)

I want to automatically save the file when a element has a download attribute and automatically open the file when download attribute does not exist. Currently it is not possible for PDF files. If I choose "Open in Firefox", PDF files will open in both cases. If I choose "Save File", PDF files will be saved in both cases.

Firefox/gecko treats download the same as Content-Disposition: attachment. Wanting files like that to behave the same way as files without it was the most-duplicated feature request in Firefox before it was fixed (bug 453455). Wanting to change how download attribute vs Content-Disposition: attachment gets treated was extensively discussed in bug 1756980 but ultimately not done. If you feel strongly that we should differentiate between those two "download" hints from the website, you can file a separate bug - it's orthogonal to the private window issue that this bug is about. I don't see us wholesale reverting bug 453455.

This is possible for other file types such as .txt. I made a testcase. When you click "View", the text file will open in Firefox. When you click "Download", the text file will be saved. This behavior is not possible for PDF.

Per the above, your testcase would break if the server sent Content-Disposition: attachment headers for the file. It otherwise works for txt only because that is a mimetype (text/plain) that the browser can render natively. It "works" for all such types, but no other ones. As a result, it doesn't work for PDF because that's rendered by PDF.js, not the browser (it's not treated the same as HTML/txt/images/media which the browser can render itself). So it's less that we did something different for PDF, and more that we [still] treat PDF like "all the other files" in this respect. Again, I think this is mostly orthogonal to this bug. Yes, it would potentially help some users with this issue as regards PDFs, but would not help for any other filetypes and would not help cases where the website choice ("download" vs "show") isn't the one the user wants.

Comment 29

[Masatoshi Kimura [:emk]]

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

Again, I think this is mostly orthogonal to this bug.

OK, I'll file a separate bug.

Comment 30

[:Gijs (he/him)]

Romain has indicated he'll look into this from a product perspective.

Comment 31

[loklomleaofgn321]

Please consider this use case:

1. Go to https://filesamples.com/formats/pdf
2. Click on the "Download" button for any of the 3 files.
3. The file is saved in the "download" folder and then opened in Firefox.
4. Click on the "Save" in the the Firefox PDF viewer.
5. The "Save-as" dialogue appears with the file chooser pointing to the "download" folder.
6. Clicking on the save button cause a "file already exists with the same name warning" with the option to replace the current file.
7. Clicking "Yes" causes a "This file is set to read-only. Try again with a different file name."
8. To save the file the user need to change the file name.

Comment 32

[Romain Testard [:RT]]

James, can you please help with this one since I'm now moving to platform?

Comment 33

[Ray Fambro]

I will take a look at this @Romain

Comment 34

[Ray Fambro]

Had a chance to catch up on this thread and speak with Gijs. Let’s provide a patch to trigger pdf files opened by Firefox to sustain (not automatically deleted from Downloads) in private windows. We will also add an about:config pref for users that want revert the behavior for PDFs, and a pref for users that want to avoid deleting any files downloaded in private browsing.

Comment 35

[Simon Friedberger [:simonf]]

So, if you use PBM to search for help on finding a new job all the PDFs you look at will end up in your Download folder. This just doesn't seem like the right solution. Even if it is the solution we can reasonably implement.
I would prefer putting these files somewhere in the profile folder, with access carefully restricted to the current user and deleting them afterwards.

This solves the problem because an explicit download (possibly going to the Download folder) is just somewhere completely different.

Comment 36

[:Gijs (he/him)]

(In reply to Simon Friedberger (:simonf) from comment #35)

So, if you use PBM to search for help on finding a new job all the PDFs you look at will end up in your Download folder.

Only PDFs that are served as downloads. This is also what all the other browsers do in this case - no other browser I could find deletes downloads from private browsing mode. If you don't want PDFs to ever download in situations like this, toggle browser.download.open_pdf_attachments_inline to true in about:config .

It's also trivial to delete these files yourself if you don't want them in your Download folder, either using your file manager or directly from the private browsing downloads panel (context menu > "Delete" does what it says on the tin). You can also set Firefox up to "always ask me where to save files" so you can pick a custom folder for private browsing, if you prefer.

You can also flip browser.download.start_downloads_in_tmp_dir to have the files (in both private + normal mode) go back to going into the tmp folder, where the OS will (at some point, depending on OS + configuration) delete them even if we don't.

This just doesn't seem like the right solution. Even if it is the solution we can reasonably implement.
I would prefer putting these files somewhere in the profile folder, with access carefully restricted to the current user and deleting them afterwards.

I don't understand how this makes things better. People would still be confused about them being persisted in normal browsing and deleted in private browsing. They would probably additionally be confused about where the files are (~nobody knows how to find their profile folder without guidance from us), and why they are somewhere different in private browsing vs. normal browsing. It probably won't work well or at all on Linux with snap builds or similar sandboxing (never mind giving other programs access to files in the profile dir). The non-discoverability of download locations is what we solved by taking files like this out of the temp folder (and no longer deleting the files after Firefox exited) to begin with. It would also make download locations less predictable - would we only do this for PDFs? Only in private browsing mode? Only for some ("not explicit") downloads?

(And would we then need another pref for users to control which folder we use for downloads in these circumstances?)

This solves the problem because an explicit download (possibly going to the Download folder) is just somewhere completely different.

It isn't really obvious what should be counted as an "explicit" download. To a normal person, clicking a web link that says "Download this PDF" is just as much an "explicit download" as right clicking the same link and picking "Save link as...". Changing the behaviour only for one of these is a recipe for yet more (different) confusion.

Comment 37

[Simon Friedberger [:simonf]]

It would also make download locations less predictable - would we only do this for PDFs? Only in private browsing mode? Only for some ("not explicit") downloads?

Exactly,

• you want a file on your disk -> you click save in a Firefox dialog
• if you want to open it in Firefox -> you don't get a file
• if you want to mark a certain file type as "automatically download (and maybe open with program $x)" that is up to you.

The core of the problem might be this:

It isn't really obvious what should be counted as an "explicit" download. To a normal person, clicking a web link that says "Download this PDF" is just as much an "explicit download" as right clicking the same link and picking "Save link as...". Changing the behaviour only for one of these is a recipe for yet more (different) confusion.

I think that would be the trick here. Be very obvious about when a download happens if a user is in PBM, i.e. always show a "Save To" dialog. That way people can look at PDFs in Firefox as if they had opened a website and still store that file to disk if they really want to.

People would still be confused about them being persisted in normal browsing and deleted in private browsing.

No, we just always delete it. We treat it like a proper temporary file as long as it gets opened in Firefox and not "explicitly downloaded".

They would probably additionally be confused about where the files are

They don't have to know where the files are if they don't feel like they have downloaded them. So if the PDF just opens in Firefox, like any website you open, it goes nowhere. If you want to have it on your disk you download it.

I concede that the behavior of especially mobile devices has made it very hard for people to track when something happens to their files. Which is probably the root of this mess.

Comment 38

[:Gijs (he/him)]

(In reply to Simon Friedberger (:simonf) from comment #37)

People would still be confused about them being persisted in normal browsing and deleted in private browsing.

No, we just always delete it. We treat it like a proper temporary file as long as it gets opened in Firefox and not "explicitly downloaded".

(...)

They don't have to know where the files are if they don't feel like they have downloaded them. So if the PDF just opens in Firefox, like any website you open, it goes nowhere. If you want to have it on your disk you download it.

This (ie specifically not saving PDFs sent with Content-Disposition: attachment or <a download> links somewhere user-discoverable) breaks user as well as web developer expectations. There was extensive discussion about this in bug 1756980 (see also all the dupes to that bug) and bug 1772569 (and the doc linked there) where we eventually reverted that behaviour (though it's still available behind an about:config preference). There's also bug 1811830 if you're suggesting we shouldn't open PDFs in these circumstances, and "just" save them (it's hard to tell if indeed that is what you are suggesting) - but that has its own substantial baggage (primarily around whether the website expectation of what "should" happen to the PDF is the same as the user's).

I'm happy to talk about this more outside of this bug, but at this point I'd really like to keep this bug focused on implementing the solution outlined in comment 34 that product and engineering have agreed on.

Comment 40

[omgalvan.86]

Hi, I just got hit by this bug, which had been reported 7 years ago here: https://bugzilla.mozilla.org/show_bug.cgi?id=1278811

Why hasn't it been fixed yet?

Comment 41

[duckzill0r]

(In reply to omgalvan.86 from comment #40)

Hi, I just got hit by this bug, which had been reported 7 years ago here: https://bugzilla.mozilla.org/show_bug.cgi?id=1278811

Why hasn't it been fixed yet?

The reason is probably, that - for a long time - it was considered deliberate behavior and it was decided that files downloaded while on PBM should be removed, except if explicitly saved (again). So it never really was considered a bug, more a question of user experience.

Anyway, as far as I understand the comments above, they now made a decision to change that (to me, odd) behavior. we just have to wait until the patch lands.

Comment 42

[whitecat6142+git]

I'm using 113beta, and I want to disable this behavior. Can I change it?
It removes manually downloaded pdfs in my Download folder.

Comment 44

[Djfe]

I just ran into this on Windows.
Nightly 116.0a1 (2023-06-11)

For me it wasn't expected behavior.
I wanted to download files from Google Drive without leaving my google account info for the user who uploaded the file.
When clicking on the download button in Google Drive, it downloads the file (download menu flashes and shows how it downloads the file to my drive), then afterwards it opens a new private tab to also view the file from my downloads folder.
If I just wanted to view the file, I

If this is expected behavior, then the help pages should reflect this. Currently they don't indicate this at all:
https://support.mozilla.org/en-US/kb/private-browsing-use-firefox-without-history#w_what-does-private-browsing-not-save
And the download menu shouldn't flash and keep showing the download (after the tab is opened) or atleast it shouldn't list the file as a download but a temporary file. Just anything that indicates that it will delete the file eventually when the user exits the session (which could be way later).

Comment 45

[Djfe]

*If I just wanted to view the file, I would've used the preview in Google Drive instead of the explicit download button.

Comment 46

[alexander.kern]

I would expect files that are opened in Firefox to get deleted. That's okay.

But I'm surprised files that use the "download" header to get deleted no matter whether my settings for that MIME type are to save the file or view the file in Firefox. When a page says "download" and Firefox help pages say downloads do not get deleted that seems confusing to me.

As a workaround I have changed the settings to always ask me whether to view or save ("download") a file in about:preferences#general. Maybe that's useful to someone.

Seems like Mozilla wants to change that behavior. Great :-) Thanks to the team

Comment 47

[Bruno Harbulot]

(In reply to Simon Friedberger (:simonf) from comment #37)

They don't have to know where the files are if they don't feel like they have downloaded them. So if the PDF just opens in Firefox, like any website you open, it goes nowhere. If you want to have it on your disk you download it.

Indeed, as a user, if I can see the address bar showing something like file:///.../Downloads/somefile.pdf (and if I can see that file in the Downloads folder), I feel like I've downloaded it, irrespectively of how that tab was opened.
(I wouldn't feel like I've downloaded those files if they'd been in a temporary folder.)

At that stage, taking an additional download step is a bit clunky:

• If I do explicitly click on "Save" from the embedded PDF viewer, then it asks me whether I want to overwrite the very file that is open in this tab.
• On Windows, what's worse is that it refuses to overwrite it because it's already open in read-only mode, so it has to be renamed or saved in a different location.

Comment 48

[exercismnow]

Can confirm that I've experienced this behavior when download PDF and epub ebook files in a Private Browsing Window, for the purposes of reading later.

Imagine my surprise when, after I'd closed the Private Browsing window, only the epub files were left! I had just taken a cursory glance through one of the PDF files, and, to use somewhat sensational ableit accurate language, I felt gaslighted by my own browser!

To test this, I opened another Private Browsing Window and downloaded the files again, but this time copying all of them to a different folder. Sure enough, after I'd closed the Private Browsing Window, the PDF files in my Downloads folder disappeared. Good thing I had made a copy, because they were rather large (~200MB), and it would've taken a while to download them again.

I have no idea why the browser would think I'd want to discard PDF files, while giving epub files special treatment. It seems counter-intuitive to me, as I would always expect files that I've purposefully downloaded to be retained. For any users discovering this the hard way, it feels like a waste of time and bandwidth.

Comment 50

[Karl]

I think it is a disastrous behaviour if files that are in my Downloads directory disappear at some later time (I keep firefox open for weeks, so actions when closing it are not helpful against clutter anyway, and they come as a total surprise). I want to rely on the Downloads directory to belong to me, and nothing interfering with it. Usually my Firefox ended because it dies or a machine crash (therefore it had no opportunity to perform the delete), so I haven't spotted this fact for a long time, and only noticed it just now. To me the fact that I can open and save at the same time was a convenience, and before the location change, i sometimes picked the files I want to keep from the temp directory and moved it to Downloads, whereas now i need no longer do this because that's already where they are, and i delete the ones I don't want to keep instead. But if at some later time files I wanted to keep are removed from my Downloads directory, this is inacceptable.
If files are temporary, firefox should use a temp subdirectory of Downloads (seeing that the tmp directory elsewhere is no longer used due to certain permission/access issues I need not understand), even more so as I do not have a choice where to store it when choosing open.
It would mean I have to "rescue" my Downloads directory elsewhere to avoid unexpected loss of data as I haven't tracked how I opened each file there, which totally defeats the very meaning of that directory.

Comment 51

[Karl]

(In reply to Bruno Harbulot from comment #47)

At that stage, taking an additional download step is a bit clunky:

• If I do explicitly click on "Save" from the embedded PDF viewer, then it asks me whether I want to overwrite the very file that is open in this tab.

I doubt that this will perserve it - if during opening it was put into a list of filenames to be deleted at a later time, and the deletion is executed, it will not know whether the file there is still the one that was downloaded. Hell, if you filled in a form and saved it in the same place, Firefox will destroy your work - silently and at an unexpected time.

Comment 52

[sirius.cybernetics]

In Firefix Android 122.0 (Build #2015998391) and older, this is not limited to pdf files. I can replicate the behavior with .mp4 video files too! I lost 30 minutes of viewing/saving promo videos and another 10 minutes trying to figure out where the heck they went. I had opened a few of them from the Gallery app and subsequently opened them in a video player to check the sample rate of the files themselves. So imagine my surprise when I could see the files in the multitasking window selector but there were nowhere on disk to be found!

I use Private to have 2 users logged in to advertising sites at the same time, however, if you Hold > Save an mp4 while it is opened directly in a tab , Firefox will delete every single one from your Download folder upon closing the tabs.

The sites aren't public for me to share, however opening any mp4 directly and then saving it should work. I suspect ANY file opened directly will exhibit this behavior, such as "open image in new tab".

Comment 53

[sirius.cybernetics]

Easy way to replicate:

Go to McD's website
Hold down on picture of burger > Copy Image Location
Paste into Private tab
Hold > Save
Check File Browser, image is there
Close Private tab
Image is gone

I worry someone testing a local file like html will open it in Private browse for a test and it will nuke the file after...

Comment 54

[Djfe]

this only affects files downloaded by Firefox not opened in Firefox.
The worry about testing a local html file is unfounded.

I still want Firefox to keep downloads permanently on my drive. Private browsing might not be about leaving traces behind, but downloads are a different category imo. Noone expects this behavior.

Firefox should (atleast!) warn before deleting the file that it is about to do so due to closing the private tab/session.
And allow you to keep the file/certain files (checkbox selection list if there are several)

Comment 55

[Karl]

(In reply to sirius.cybernetics from comment #53)

Easy way to replicate:

Go to McD's website
Hold down on picture of burger > Copy Image Location
Paste into Private tab
Hold > Save
Check File Browser, image is there
Close Private tab
Image is gone

I just checked with Firefox 120.0 on Linux, in a private window, right-click on an image, save image as, and it persisted after closing the (only) private window (bloody hell if it didn't after I explicitly saved it)
So this seems to be platform specific and is based on a different process (save rather than open, private only), and you should open a new bug for it, because it does not belong here, this bug is for platform "Desktop All".

Note that the scenario you describe might be better served by the Firefox feature "container tabs". Each container (as well as the "no container") has its own set of cookies, so you can use them for concurrent logins, and they persist across sessions.

Comment 56

[sirius.cybernetics]

I just checked with Firefox 120.0 on Linux, in a private window, right-click on an image, save image as, and it persisted after closing the (only) private window (bloody hell if it didn't after I explicitly saved it)
So this seems to be platform specific and is based on a different process (save rather than open, private only), and you should open a new bug for it, because it does not belong here, this bug is for platform "Desktop All".

Note that the scenario you describe might be better served by the Firefox feature "container tabs". Each container (as well as the "no container") has its own set of cookies, so you can use them for concurrent logins, and they persist across sessions.

Oh I'll check out the container tabs feature, thanks!

Comment 57

[:Gijs (he/him)]

(In reply to sirius.cybernetics from comment #52)

In Firefix Android 122.0 (Build #2015998391) and older, this is not limited to pdf files.

This bug is for Firefox on Desktop. Please file a separate bug for Firefox for Android.

Comment 58

[Wacbsclx]

Windows here.
I noticed the issue isn't whether or not the downloads are saved by default, the "downloads" tab is opened and shows the file in the disk/downloads folder. Then when the session is closed, they are removed from disk. It's misleading to show firefox seemingly having downloaded something without actually being a real save. If Firefox means to simply "view only" with the open-in-browser, then it should not show the prompts of the download happening.

Comment 59

[timetraveller]

(In reply to Karl from comment #55)

(In reply to sirius.cybernetics from comment #53)

Easy way to replicate:

Go to McD's website
Hold down on picture of burger > Copy Image Location
Paste into Private tab
Hold > Save
Check File Browser, image is there
Close Private tab
Image is gone

I just checked with Firefox 120.0 on Linux, in a private window, right-click on an image, save image as, and it persisted after closing the (only) private window (bloody hell if it didn't after I explicitly saved it)
So this seems to be platform specific and is based on a different process (save rather than open, private only), and you should open a new bug for it, because it does not belong here, this bug is for platform "Desktop All".

Note that the scenario you describe might be better served by the Firefox feature "container tabs". Each container (as well as the "no container") has its own set of cookies, so you can use them for concurrent logins, and they persist across sessions.

Hi, it is not platform specific. Just happen me on linux. It probably happens only on files which are opened after downloading (like pdf).

Se original 8 y.o. bug also with possible place in code: https://bugzilla.mozilla.org/show_bug.cgi?id=1278811#c14

Comment 60

[edu.clemens]

In my opinion this is a very critical bug and I can't believe it has been around for a long time without a solution.
I just went back to Firefox and I was doing my taxes, for which I use the private mode so prevent issues from any of my addons installed.
I completed my taxes, downloaded my confirmation in a PDF document, checked and opened the document in my "Downloads" folder, and closed the browser as everything was ready.
But when I wanted to move my document in my "Downloads" folder I discover that the file is no longer there. I thought, maybe I had moved it or deleted it by mistake, but it was nowhere to be found, not even in the recycle bin.
I have already tested several PDFs, and when I close my private browser, I see the file magically disappear from my "Downloads" folder.
Like others, I think this should not happen. Or at least not without a previous warning, or in case this is the an expected behavior, these files should never been in the download folder, and use some temporary folder.
I hope Mozilla someday hears use and fix this.

Comment 61

[daniel]

I second that, Clemens.

Just started a quarrel with my online banking provider for "deliberately deleting files from my local drive"...
I understand there are controversies involved which have to be taken under consideration. And it is only professional to do so, so a big thank you to all contributors!

Please consider this a bare - yet obviously not single - user experience remark:

What is - with according system confirmation - downloaded to my download folder is considered my property by myself.
No matter the file format, no matter any security settings.

To me, under no no no circumstances is my browser to interfere with files I gained ownership upon. In contrast to tmp, the download folder is mine. Flagging for malware and transparent virus scanner action are the only interference that I would consider legitimate.

Again, I understand there is more to the issue than just this perspective, but as for me, it is prone to cause serious trust issues. I mean I log into my bank account, fetch my numbers, see and even interact with the download, close the browser and it's gone? More disturbingly so: xls remains but pdf will be deleted by.... someone... I get the reason here, still this behavior can't be anticipated.

Thanks to all you out there making firefox that great as it is - I would not be so upset about this one if I wouldn't consider it my trusted holy grail by all means.

Comment 62

[Nikolaos Chatzikonstantinou]

The design is broken irrespective of privacy issues, Firefox shouldn't be deleting files under ~/Downloads. It shouldn't save privacy-sensitive files in ~/Downloads. This ephemeral behavior should be reserved for /tmp or /.cache. Even worse, this behavior (for PDF files) is depending on whether it is viewed in-browser or not. If I see file:////Downloads in the address bar, I am not expecting it to be deleted.

Discussing this further is a waste of time, just move all the files to /tmp or ~/.cache, and preferably /tmp: it's naive to download privacy-sensitive ephemeral files to ~/Downloads which typically is mounted on disk, while /tmp is mounted on RAM. How is Firefox deleting files from disk? Can Firefox guarantee that digital forensics will fail? The reasonable thing is to put such things in RAM.

Comment 63

[lucas]

I'm chronically affected by this.

Firefox private windows will randomly delete downloaded files I've saved on my computer.

As others have pointed out this bug seems to be triggered by invisible HTML settings that vary randomly by website, and aren't obvious to the end user.

As a firefox user of over a decade I'm flabbergasted the community has abided such a critical data integrity bug like this for years.

The only suggested remedy is to disable all pdf viewing functionality of firefox.
I cannot find the browser.privatebrowsing.deleteDownloadedFilesAtRandomOnClose: true setting in about:config.

I know nothing of the firefox codebase, but I'm willing to spend up to 2 weeks creating a patch for this, since I am constantly by this issue seemingly randomly.
Even if the patch and fix are to be rejected by the community here for another 2 years, then maybe a FF fork can use it, so I and others are not forced to switch to that other browser.

Comment 64

[pheki]

Hey, I wanna give deeper insight on the user perspective and make it clear of what I think is the UX problem and also why I think this is a serious issue. I'll also suggest a workaround at the bottom.

Before Firefox 98, if you were trying to download a file firefox would ask if you wanted to "Open" or "Save" it. This choice implied to the user that you weren't saving the file when choosing to open. The file was also nowhere to be found and you could see on the URL bar that it was on a random temporary directory, so it didn't feel like the file was persisted.

On Firefox 98 all of this changed, especially for PDFs, AVIFs and WebPs, which are now by default "Open in Firefox". When the user clicks "download" on sites, Firefox will just start downloading the file and then open it. The file will be on the downloads folder and it will also show there on the URL bar. Everything indicates that the file has been persisted, so there's no need to download it again... In fact, the way to "persist" the file in that case is to click the download button on the PDF viewer, but if you try to save it in the Downloads directory (the default path), it will ask the user to confirm if they want to overwrite, so it doesn't even make sense to try to download it again.

And that's why I think this should be high priority, this is a very destructive action for all 3 file formats. For PDFs, it has a lot of damage potential as it can remove receipts, banking and tax statements, etc.

Suggestion 1:

• Stop deleting files that have already been saved
• Rename "Open in Firefox" to "Save and Open in Firefox" and "Open" to "Save and Open"

Suggestion 2:

• Revert "only opened" file types to go to a temporary directory and get auto-deleted, on both private and normal windows

Workaround

For everyone reading this while this isn't fixed, I recommend going to Settings (about:preferences) -> General -> Applications and change all "Open in Firefox" to "Save File" or "Always Ask"

Comment 66

[:Gijs (he/him)]

There was already a product decision on what should happen here in comment 34 - it "just" hasn't been implemented yet; for that, engineering time needs allocating. Comments here don't help with that. At this point (another 30 comments later) further comments aren't adding novel information so I'm going to disable new comments.

Comment 67

[Becca]

Attachment: Bug 1790641 - Only delete downloaded files in private browsing if deletePrivate pref is set to true - r=mak,mconley

Comment 69

[Becca]

Attachment: Bug 1790641 - Only delete downloaded files in private browsing if deletePrivate pref is set to true - r=mak,mconley

Comment 70

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/bc3589ef6865
https://hg.mozilla.org/integration/autoland/rev/b59fefc9b1a9
Only delete downloaded files in private browsing if deletePrivate pref is set to true - r=mconley,fluent-reviewers,settings-reviewers,desktop-theme-reviewers,hjones,bolsson,mossop

Comment 71

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/15827c56bc55
https://hg.mozilla.org/integration/autoland/rev/0f2554ded32e
Revert "Bug 1790641 - Only delete downloaded files in private browsing if deletePrivate pref is set to true - r=mconley,fluent-reviewers,settings-reviewers,desktop-theme-reviewers,hjones,bolsson,mossop" for causing download related xpcshell failures.

Comment 72

[Cosmin Sabou [:CosminS]]

Backed out for causing download related xpcshell failures.

Push with failures

Failure log

Backout link

Comment 73

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/86d5562af234
https://hg.mozilla.org/integration/autoland/rev/2292c4106128
Only delete downloaded files in private browsing if deletePrivate pref is set to true - r=mconley,fluent-reviewers,settings-reviewers,desktop-theme-reviewers,hjones,bolsson,mossop

Comment 74

[amarc]

https://hg.mozilla.org/mozilla-central/rev/2292c4106128

Comment 75

[Negritas Sergiu, Desktop QA]

Hello! I have managed to reproduce the issue with firefox 141.0a1(2025-05-30) on Ubuntu 22.04, MacOS 15.6 and Windows 10. I can confirm that the issue is fixed with firefox 141.0b4

I will update the status and flags of this issue.

Have a nice day!

Comment 76

[Pascal Chevrel:pascalc]

(In reply to Negritas Sergiu, Desktop QA from comment #75)

Hello! I have managed to reproduce the issue with firefox 141.0a1(2025-05-30) on Ubuntu 22.04, MacOS 15.6 and Windows 10. I can confirm that the issue is fixed with firefox 141.0b4

I will update the status and flags of this issue.

Have a nice day!

Hi Sergiu, should the steps in comment #8 lead to the downloaded file not being deleted after closing the private window? We got a report by an affected user on Element that the bug is not fixed for them in Devedition 141.0b4. I just tried myself and indeed, the downloaded file is deleted from the disk after closing the private window. Is that the expected outcome? Thanks

Comment 77

[Dave Townsend [:mossop]]

I've filed a new bug for this issue, bug 1975413, because while the work here landed it is all behind a currently disabled preference and we need to decide to actually enable that preference for users.

Comment 78

[Negritas Sergiu, Desktop QA]

Hello Pascal! I have not tried the fix with firefox devedition, and the steps from comment 8 are the ones I have used to reproduce the issue and also to see if the issue is fixed.