Steps to reproduce:

0. This seems intermittent. I don't know if I have identified a step that makes it nonintermittent.

1. Check that Firefox > about:preferences > General (in left navbar) > Files and Applications > Downloads > "Always ask you where to save files" radio button is preselected. I don't remember if you have to save your preference by exiting and restarting FF. In my case, the preference was set before at least one cold-boot and many warm-boots.

2. Go to a Web page that offers a PDF for downloading. Example: https://www.irs.gov/forms-pubs/about-publication-501 (where the "PDF" link is to https://www.irs.gov/pub/irs-pdf/p501.pdf).

3. Click FF's icon for downloading. It's in the upper right corner of the viewport.

4. In the dialog for your next step, select the Save File radio button, if it's not preselected.

5. Sometimes, in FF's Save-As dialog, I try to create a directory, but an alert says that the filesystem is read-only and so the folder cannot be created. However, if I go to the Files app (Nautilus) and do not change any permissions, I can create the directory there and then I can come back to FF's save-as dialog and, without changing permissions, save in the directory I made in Nautilus. Possibly, this R/O problem

Actual results:

FF sometimes doesn't ask where to save the file (although many times it does). If it doesn't ask, it saves to /Home/.var/app/org.mozilla.Firefox/cache/tmp/mozilla_<nonroot-account-name>0 . That directory has a bunch of files with .pdf.part files with possibly-random filenames I don't recognize. My Fedora installlation does not list an app that opens .pdf.part files.

In the downloading process, the "OK" button took about half a second to become clickable. Also, if I alt-tab to gedit and alt-tab back to FF, the dialog's "OK" button took about half a second to become clickable.

When it fails to ask, subsequent downloads of the same file do not report or caution about overwriting. Apparently, part of each download is saved with a new name but in an unusable format.

When I exited and restarted FF and tried to download the above PDF, FF proposed to download to <nonroot-account-name>/Downloads , I switched to a desired location, and clicked to download; but no downloading resulted.

When downloading failed as here with one PDF, copying the PDF's URL into Chromium 88.0.4324.150 (Developer Build) Fedora Project (64-bit) and downloading from there succeeded without a hitch. But I'd rather use FF.

A kludgy solution was to download with the Open radio button selected, and when it opens with the system handler, Document Viewer (Evince), version 3.38.1, go to the hamburger menu > Save As. Doing so with https://www.irs.gov/pub/irs-pdf/p535.pdf showed the planned destination as above (. . . /mozilla_<nonroot-account-name>0), which revealed that the desired PDF was already there. Repeating the kludge had the same result even though I had not clicked OK to Save File but only selected the radio button to Open without clicking OK. This, according to the Files app, got a .pdf.part file in . . . /mozilla_<nonroot-account-name>0 but when I went back to click the OK to Open then the .pdf.part file became the PDF I wanted, 2.1 MB and with a lock icon, although I then deleted it without unlocking it.

FF's version was 85.0.1 (64-bit) and the problem continues in 86.

I don't know the component.

Reported over a week ago to the distro bug tracker because of a claim that if it's a Gnome bug it must be reported to the distro's tracker first: https://bugzilla.redhat.com/show_bug.cgi?id=1932718

Expected result: When consistent with the pref, FF should always ask where to save the file.

Does that also happen in a fresh user profile with zero extensions and zero add-ons?

Reported over a week ago to the distro bug tracker because of a claim that if it's a Gnome bug it must be reported to the distro's tracker first

Errm, then why was a duplicate ticket reported in Mozilla Bugzilla?

I'll get to your first part soon (time is short now).

I reported here because there's no answer there and because it seems to be a Firefox problem rather than a distro problem or a Gnome problem, and a bug in an app gets reported to the app's bug tracker (the reason apps have their own bug trackers).

Hey Nick,
I tried to reproduce this issue on the latest versions of Firefox Nightly 88.0a1 (2021-03-11), beta 87.0b8 or release 86.0 on Ubuntu 20.04 but couldn't.

Can you test the issue while in Safe Mode? You can find helpful info here : https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode .
Also a fresh new profile could help. You can find more about creating a new profile here : https://support.mozilla.org/en-US/kb/troubleshoot-and-diagnose-firefox-problems#w_6-create-a-new-firefox-profile .
If possible, you can test this issue on the nightly build as well. Download the build from : https://www.mozilla.org/en-US/firefox/nightly/all/ .

I removed FF and then reinstalled it using dnf and then the problem in this thread was solved, although kludgily. dnf installed firefox-86.0-7.fc33.x86_64; I think that's a later minor version than I had through Fedora. But "Flatpak is installed by default on Fedora Workstation." Https://flatpak.org/setup/Fedora/ (as accessed 3-14-21). That suggests that the default way I'll get FF into Fedora is via Flatpak. And what Flatpak installs seems more secure than what dnf installs. People commenting at Reddit (https://www.reddit.com/r/Fedora/comments/g56m8n/whats_the_difference_between_firefox_from_dnf_and/) say there's a security difference favoring the Flatpak FF over the dnf FF.

dnf is not a good solution, since the FF we get through the Software app should work and may be more secure. Only a geek would install through dnf instead, and most people are not geeks. I removed FF via dnf and reinstalled it (version 86.0 (second decimal group not found), build 20210304154255) using the Software app and set FF to safe mode. It appears that I have no extensions and that the only add-on I have is disabled and not uninstallable. I assume any new installation of FF creates a new user profile, and there's only one user profile, which has the settings I like and which probably are the ones I usually have. This reinstallation via the Software app was thus through Flatpak, and the problem came back.

I didn't try a nightly build, due to time (I'd also have to uninstall the regular FF and then reinstall it afterwards), but I don't thhink I need to now.

Since Flatpak is not something I explicitly use, but use only implicitly as part of the Fedora/Gnome installation, then the bug is somewhere in the FF that Flatpak supplies for Fedora or is in Fedora, Gnome, Flatpak, or the Software app. Perhaps someone can help narrow down the suspects.

This likely contributes to many bugs experienced by users as FF bugs.

There are a few different issues here:

5. Sometimes, in FF's Save-As dialog, I try to create a directory, but an alert says that the filesystem is read-only and so the folder cannot be created. However, if I go to the Files app (Nautilus) and do not change any permissions, I can create the directory there and then I can come back to FF's save-as dialog and, without changing permissions, save in the directory I made in Nautilus. Possibly, this R/O problem

This seems like a flatpak permissions/sandboxing issue that I'm not sure we can resolve, but if anything it would be resolved through the GTK integration code, so moving this bug there as it seems the most actionable issue right now.

FF sometimes doesn't ask where to save the file (although many times it does).

We don't ask if you select the "open" option - we will save to a temp folder and delete the file when Firefox is shut down. We have some plans to change how downloading works (likely to happen in Q3 this year) and this may also change, but we won't change this individually.

If you select "save" we should always ask. If you have steps to reproduce where this isn't the case, please file a separate bug with precise steps to reproduce that issue.

In the downloading process, the "OK" button took about half a second to become clickable. Also, if I alt-tab to gedit and alt-tab back to FF, the dialog's "OK" button took about half a second to become clickable.

This is a security feature to prevent clickjacking / keyboard hijacking of the options in the dialog by websites.

When it fails to ask, subsequent downloads of the same file do not report or caution about overwriting. Apparently, part of each download is saved with a new name but in an unusable format.

While downloading (even while the "what do you want to do with this file" dialog is being shown!) we already save the file in the temp folder. There are a few reasons for this, but the most important is what is happening behind the scenes: when we show the dialog, we have made a request to a server and the server has sent Firefox data. The data needs to go somewhere. If we were to restart the request, we might get a different response, so we cannot just abort the request and wait for you to make a decision and then re-execute it. Storing the data in memory is also a bad idea with today's fast internet connections - we'd gobble up a lot of RAM very quickly and then users would also be annoyed. We can't even rely on servers' initial report of the filesize of the download (Content-Length) because it is frequently wrong or missing. So instead the data is stored on disk in the temp directory, and is moved/renamed once the file is completely downloaded and the user has chosen a destination or an app to open the file with. The .part extension indicates that the file is not complete and not ready to be opened in another app. Other browsers do the same thing but with different extensions (IIRC Chrome uses something like .chromium-download or whatever).

When I exited and restarted FF and tried to download the above PDF, FF proposed to download to <nonroot-account-name>/Downloads , I switched to a desired location, and clicked to download; but no downloading resulted.

This too would be useful as a separate report with more detailed steps. But it's difficult to diagnose several distinct problems in a single bug, even if to you they all seem related.

For what it's worth, I've hit this issue. I've solved it (possibly not the best way) but here are the findings.

1. Flatpak sandboxes are pretty exclusive by default, and they refresh when the child application restarts.

2. Apps like FlatSeal can help by altering the starting config options. (in my case, I added ~/Downloads to the list of "Other Files" in "Filesystem". I've also added xdg-download

3. Flatpak uses XDG-* environment variables by default. Reportedly, if you set specific environment vars, those might be used by the various Flatpak app configurations. so export XDG-DOWNLOAD=$HOME/Downloads should tell Flatpak to mount the Downloads directory if the app is set to read xdg-download

4. It's also possible to set filesystem=home in which case the flatpak will use the user $HOME directory as it's own $HOME. That may be more like what folks expect, but also means that everything in the $HOME directory is exposed to the app.

No idea if these are useful, but they helped me figure out what the heck was going on.

On comment 5:

On Flatpak and GTK: Sounds fine to me.

"We don't ask [where to save] if you select the 'open' option . . . ." Yes, but I was selecting to save and it still sometimes wasn't asking where to save even though asking is already my pref. I did give STR but, as stated above, not without intermittency; I don't know (yet) what causes it that would yield nonintermittent STR.

Clickjack and keyboard-hijack prevention: That's good. Since reporting this, I've noticed that delay elsewhere. It's not an issue for me now.

Downloading before a user's save-as decision makes sense. It brings out a question about why I accumulate so many never-finished downloads, but I guess that may get solved as a byproduct of solving the main problem.

On proposing a separate bug report for "When I exited and restarted FF and tried to download the above PDF, FF proposed to download to <nonroot-account-name>/Downloads , I switched to a desired location, and clicked to download; but no downloading resulted.": I plan to take another look.

On comment 6: You know much better than I do.

In response to comment 5:

"FF sometimes doesn't ask where to save the file (although many times it does).": See bug 1703335, which effectively updates what I wrote in comment 7 above ("'[w]e don't ask [where to save] if you select the 'open' option . . . .' Yes, but . . . .").

"On proposing a separate bug report for 'When I exited and restarted FF and tried to download the above PDF, FF proposed to download to <nonroot-account-name>/Downloads , I switched to a desired location, and clicked to download; but no downloading resulted.': I plan to take another look." I think this is taken care of by the new bug report mentioned in this comment and by prior discussion in this report.

FF sometimes doesn't ask where to save the file (although many times it does). If it doesn't ask, it saves to /Home/.var/app/org.mozilla.Firefox/cache/tmp/mozilla_<nonroot-account-name>0 . That directory has a bunch of files with .pdf.part files with possibly-random filenames I don't recognize. My Fedora installlation does not list an app that opens .pdf.part files.

Does the GTK file chooser dialog fails to open or the Open with Firefox/Open with/Save file fails to open? In case the GTK file chooser fails to open it seems to be problem with the portal invocation. The .part files are fine, they're created before user choose the opening method or set the filename to speed up downloading.

This is very similar to bug 1703335, could you please give us distro details, like:

rpm -qa \*xdg-desktop-portal\*
rpm -qa flatpak

and Desktop Environment you use.
I cannot reproduce in on Fedora 34/Gnome 40.

On comment 9:

"Does the GTK file chooser dialog fails to open or the Open with Firefox/Open with/Save file fails to open?": When a dialog for saving-as fails to open, I can't see what it is that is not opening. So, I don't know how to answer your question.

The .part files would just be a minor annoyance I'd hardly notice until there are a lot of them and I don't know whether I can delete them because I don't know why they're there. However, because they represent parts of files that I wanted but that I'm not getting in openable form, that's much more critical.

rpm -qa *xdg-desktop-portal*

got:

xdg-desktop-portal-1.8.1-3.fc34.x86_64
xdg-desktop-portal-gtk-1.8.0-2.fc34.x86_64

rpm -qa flatpak

got:

flatpak-1.10.2-3.fc34.x86_64

For the DE, I use Gnome 40.1, with Fedora 34, kept evergreen.

What may be lost in this discussion is that the problem does not occur the first time but does on subsequent tries. (That was originally in the Summary of bug 1703335 but got taken out of the Summary there.) I've now noticed more about that characteristic: I went to the IRS page listed in STR step 2 above and downloaded the PDF listed in that STR. I could twice, being asked where to twice. But when I went to another IRS page and chose something else to download during the same Firefox session, it did not show me a dialog for where to save-as to. Instead, it saved to its default location, despite my pref that FF ask (I just checked the pref).