[Flatpak] when saving download, FF doesn't ask where to despite pref, or doesn't reliably save to that destination
Categories
(Core :: Widget: Gtk, defect)
Tracking
()
People
(Reporter: Nick_Levinson, Unassigned)
References
(Blocks 1 open bug)
Details
This responds to "If you select 'save' we should always ask [given the preset pref]. If you have steps to reproduce where this isn't the case, please file a separate bug with precise steps to reproduce that issue." (https://bugzilla.mozilla.org/show_bug.cgi?id=1697086#c5).
STR:
0. This seems intermittent. I don't know if I have identified a step that makes it nonintermittent.
- 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.
- Go to a Web page that offers a PDF for downloading. Example this time: https://www.irs.gov/forms-pubs/about-form-2290
- At that page, download a PDF by clicking under "Current Revision" the link text "Tax Year 2020 Form 2290 (Rev. 202007) . . . PDF" to open in the same tab. (The link destination is https://www.irs.gov/pub/irs-pdf/f2290.pdf .)
- Click FF's icon for downloading. It's in the upper right corner of the viewport.
- In the dialog for your next step, select the Save File radio button, if it's not preselected.
- If it offers (as it should per the pref) to save to the Downloads directory, change the destination to the Documents directory.
Actual result:
FF doesn't always ask.
In this case, it asked the first time but didn't execute my request and it didn't even ask the next few times. After nothing landed in the Documents directory, twice when I clicked FF's download icon again in the same tab with the same PDF document that was already in the tab, I chose to save but FF did not ask me where to save to. Then I got i6y63W2x.pdf.part and xavXShA0.pdf.part in the subdirectory deep inside /Home/.var/ directory, not where I wanted. When I went to the tab with the PDF, went back a page, and clicked to download the PDF again into the same tab, again it didn't ask and the same bad result happened (i6y63W2x.pdf.part elsewhere). Then I went to the tab with the PDF, went back a page, and clicked a different the link text, the one for "Tax Year 2020 Instructions for Form 2290 (Rev. 202007) . . . PDF", to open in the same tab but again it didn't ask and I got the same bad result (G98fORoe.pdf.part). Then I copied the URL for the page with the links to PDFs, closed the tab, opened a new tab, pasted the URL into that tab, selected a new link text ("Tax Year 2019 Form 2290 (Rev. 201907) . . . PDF" with destination https://www.irs.gov/pub/irs-prior/f2290–2019.pdf), and I downloaded into the same tab. I saved but FF didn't ask me where to save to and Kw5coXRJ.pdf.part landed where I didn't want it. Then, keeping the tab open, I opened a new tab, pasted the URL with the links to PDFs, selected a new link text ("Tax Year 2019 Instructions for Form 2290 (Rev. 201907) . . . PDF" with destination https://www.irs.gov/pub/irs-prior/i2290–2019.pdf), downloaded the PDF to the same tab, clicked the FF download icon, and chose to save, but was not asked where to save to, and the resulting file (dZMZiY0e.pdf.part) landed elsewhere. Then, keeping other tabs open and opening a new tab, I went to another page in the same website (https://www.irs.gov/forms-instructions), selected the link text "Form W-4 . . . PDF" (destination https://www.irs.gov/pub/irs-pdf/fw4.pdf), downloaded the PDF into the same tab, clicked FF's download icon, and opted to save but was not asked where to (and got eySljp0T.pdf.part). Then, keeping all tabs open and opening a new tab, I went to another website (https://www.tax.ny.gov/forms/orpts/star.htm), selected the link text "RP-425-B (Fill-in)" (destination https://www.tax.ny.gov/pdf/current_forms/orpts/rp425b_fill_in.pdf), downloaded the PDF into the same tab, clicked FF's download icon, and chose to save but was not asked where to and got buBM8WcW.pdf.part with a plain-text icon and saved elsewhere than I would have selected if asked. I can't open a new FF window when FF is open so I exited FF and restarted it, went to a another website (https://portal.311.nyc.gov/article/?kanumber=KA-01013), selected the link text "Download a Birth Certificate Correction Application." (destination https://www1.nyc.gov/assets/doh/downloads/pdf/vr/bcorrect.pdf), downloaded into the same tab, clicked the FF download icon, and chose to save, FF asked where to save to and I said to save to /Documents/ , but it didn't save there (putting w7A1FNf9.pdf.part elsewhere). Again, I clicked the FF download icon and chose to save, but this time FF did not ask where to save to and it put PT7_Mm9P.pdf.part elsewhere.
FF version 87.0 (64-bit). Fedora 33 Linux, kept evergreen.
Possibly of interest: Bug 500701.
Possibly, what's happening is that FF asks the first time I save any PDF but without asking again until I exit and restart FF.
Expected result: Always ask where to save, if that's the preset pref, regardless of prior saves.
|
||
Comment 1•4 years ago
•
|
||
Hey Nick,
Unfortunately, I was not able to reproduce this issue on Windows 10 x64 Firefox Release 87.0 and Nightly 89.0a1 versions. Wondering if this is not Linux specific.
After selecting the right download preference the question regarding where to download the file always appears in my case on both versions.
Could you please try again after disabling all the addons on your computer?
Could you also please check if this is reproducible on the latest Nightly 89.0a1?
|
Reporter | |
Comment 2•4 years ago
|
||
All the addons on my computer would be too much, as I don't know what that could include, but FF itself lists only one plugin and already labels it as disabled. Then I did Menu button > Help > Restart With Add-ons Disabled. "Always ask you where to save files" remained preselected. I repeated STR 1-. The first time, it asked where to save but did not execute it; instead I found 1A+ptYdu.pdf.part in the unrequested default location (/Home/.var/. . .). I clicked the FF download icon again, this time it did not ask where to save to, and again in /Home/.var/ in the default subdirectory I found TESjecxm.pdf . So the problem is continuing even without add-ons (and FF was without add-ons when I reported the bug).
Then, 1A+ptYdu.pdf.part disappeared. I don't know how or why. I ran Search for Files with "Show hidden and backup files." turned on for *.pdf.part anywhere in /home/ and didn't find it. The PDF it was part of did not appear. Search for Files with the same settings for f2290.pdf (which should have arrived) got only "No files found".
If possibly some other app or something in the distro or that I might have installed later (I don't have a list of what was added that didn't come with the distro), I don't know how to isolate that in any useful way, because I still need to use the computer, the kernel, and many of the apps.
I have available time, so I thought I'd try the Nightly, but: Assuming it behaves as designed:
--- Does it conflict with the present FF (e.g., should I remove the present FF and reinstall it later)?
--- Does it conflict with anything else on disk?
--- Can I uninstall it in the usual way for uninstalling apps? Like, will it be separately listed in the Software app so I can remove the Nightly without removing the regular FF?
--- Is the latest Nightly good enough for your purposes? or do you need a specific one instead?
I already read https://wiki.mozilla.org/Nightly .
|
||
Comment 3•4 years ago
|
||
Does the problem still happen if you start Firefox in Safe Mode? (Safe Mode disables add-ons, extensions and themes, hardware acceleration and some JavaScript stuff in order to exclude some possible reasons for problems.) See https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode
And does this also happen with a new and empty profile? See https://support.mozilla.org/en-US/kb/troubleshoot-and-diagnose-firefox-problems#w_6-create-a-new-firefox-profile
|
|
Reporter | |
Comment 4•4 years ago
|
||
I already tested without add-ons in an earlier version of this bug report: https://bugzilla.mozilla.org/show_bug.cgi?id=1697086#c4
For the new profile: I refreshed FF. In about:preferences , I set "Always ask you where to save files". I exited and restarted FF and confirmed the setting was still selected. I repeated STR 2-6 per original post above. Actual result: File not saved in intended destination. Instead, P8b4Eek8.pdf.part appeared in /Home/ . . . /mozilla_<nonroot_user_account>0 .
Then, I went back to the PDF still in the browser tab and repeated STR 4-5 but FF did not ask where to save to and that failure was followed by the same bad result (this time with mD+8J7Q2.pdf.part in the wrong directory). Then, I repeated STR 2-5, going back to the page with the link to the PDF, with the same bad result (Vmog8j1J.pdf.part).
|
||
Comment 6•4 years ago
|
||
Is Firefox installed through Snap or Flatpak?
|
|
Reporter | |
Comment 7•4 years ago
|
||
Flatpak, to my knowledge. Various discussions in this Bugzilla have been about Flatpak as related to problems with Firefox, problems I have. It's been a while since I reinstalled using dnf. Not knowing about Snap, I checked what the Software app says for FF and it says "Source registry.fedoraproject.org". Visiting that URL didn't tell me anything. I supposedly got an update to FF via the Software app today but the FF version number has not incremented.
|
||
Comment 8•4 years ago
|
||
I can reproduce this with the steps from comment #0 if I manually install the Firefox flatpak from flathub. I honestly have no idea why this breaks - we'll get a destination from the file picker and we will ask our networking code to save to that destination, and outside of flatpak this works fine. I assume this is some kind of flatpak sandboxing feature, but I don't know why it breaks in this way. :stransky, do you know what's going on here, or can you forward to folks who know about our flatpak integration?
|
|
||
Comment 9•4 years ago
|
||
Oh, though in my case the file does get created in the Documents folder, but if I use the "Open Containing Folder" functionality in the downloads pane, it points to the /run/user/.../doc/{blah}/ directory instead. Very strange.
|
|
||
Updated•4 years ago
|
|
||
Comment 11•4 years ago
|
||
Hm, that's because the Firefox flatpak has limited access to the host filesystem:
filesystems=xdg-download;/etc/firefox/policies;
The saving to Documents is over portal which allows writing to the specific location. I wonder why it does not work sometimes, looks like a problem in the portal. To debug it further we need a flatpak and flatpak portals version and distro version, in fedora can be obtained by:
rpm -qa \*xdg-desktop-portal\*
rpm -qa flatpak
Some flatpak background:
After the filepicker dialog finished the gtk_file_chooser_get_uri is used to get the path, but the path is in the flatpak container scope - since the filesystem is limited only to Download dir, pointing to some /run/user/<uid>/doc/<etc>. The file should be also written to the picked host location. Also note that the Download manager stores the /run/user... path. Fortunately the file in the flatpak env stays mirrored with the host environment, so the file is basically the same entity (changes from host or from flatpak of the file works fine both way).
Good way to show to which files has the flatpak access is to navigate to file:///
|
|
||
Comment 12•4 years ago
|
||
(In reply to :Gijs (he/him) from comment #9)
Oh, though in my case the file does get created in the
Documentsfolder, but if I use the "Open Containing Folder" functionality in the downloads pane, it points to the /run/user/.../doc/{blah}/ directory instead. Very strange.
We can fix that by https://github.com/flatpak/xdg-desktop-portal/pull/390 I'll look into it.
|
|
Reporter | |
Comment 13•4 years ago
|
||
I'm not sure which info you want from me for the needinfo, so if I got it wrong please post again.
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
and
rpm -qa flatpak
got
flatpak-1.10.2-3.fc34.x86_64
|
||
Comment 14•3 years ago
|
||
(In reply to Jan Horak [:jhorak] from comment #12)
(In reply to :Gijs (he/him) from comment #9)
Oh, though in my case the file does get created in the
Documentsfolder, but if I use the "Open Containing Folder" functionality in the downloads pane, it points to the /run/user/.../doc/{blah}/ directory instead. Very strange.We can fix that by https://github.com/flatpak/xdg-desktop-portal/pull/390 I'll look into it.
This has been merged and I guess is likely deployed, do you still hit the issue ?
|
|
Reporter | |
Comment 15•3 years ago
|
||
I don't have the same installation anymore, can't test it, and I'm not prepared to try to make a similar-enough setup.
|
|
||
Updated•3 years ago
|
|
||
Comment 16•3 years ago
|
||
This issue still exists in the current version of Firefox in Flatpak.
|
|
||
Comment 17•3 years ago
|
||
(In reply to Devin Bayer from comment #16)
This issue still exists in the current version of Firefox in Flatpak.
Can you share more of your setup infos ? As I said, the fix is outside of Firefox and it likely deployed, maybe you dont have it yet.
|
|
||
Comment 18•3 years ago
|
||
(In reply to Alexandre LISSY :gerard-majax from comment #17)
(In reply to Devin Bayer from comment #16)
This issue still exists in the current version of Firefox in Flatpak.
Can you share more of your setup infos ? As I said, the fix is outside of Firefox and it likely deployed, maybe you dont have it yet.
I am using latest Ubuntu (22.04). In about:config I set browser.download.dir to /mnt/itch/Down, which I also have given FF access to:
$ flatpak info --show-permissions org.mozilla.firefox/x86_64/beta
[Context]
shared=network;ipc;
sockets=x11;wayland;pulseaudio;pcsc;cups;
devices=all;
filesystems=xdg-download;/mnt/itch/Down;
I can manually save there. However when I go to save or download something, the dialog defaults to /run/user/1000/doc/3bd9f0fc/, which is just a temporary folder that contains nothing.
|
|
||
Comment 19•3 years ago
|
||
(In reply to Devin Bayer from comment #18)
(In reply to Alexandre LISSY :gerard-majax from comment #17)
(In reply to Devin Bayer from comment #16)
This issue still exists in the current version of Firefox in Flatpak.
Can you share more of your setup infos ? As I said, the fix is outside of Firefox and it likely deployed, maybe you dont have it yet.
I am using latest Ubuntu (22.04). In
about:configI setbrowser.download.dirto/mnt/itch/Down, which I also have given FF access to:$ flatpak info --show-permissions org.mozilla.firefox/x86_64/beta [Context] shared=network;ipc; sockets=x11;wayland;pulseaudio;pcsc;cups; devices=all; filesystems=xdg-download;/mnt/itch/Down;I can manually save there. However when I go to save or download something, the dialog defaults to /run/user/1000/doc/3bd9f0fc/, which is just a temporary folder that contains nothing.
So this is a different issue ?
- Can you write to
/mnt/itch/Down? /run/user/1000/doc/3bd9f0fc/is a mount point managed bygvfs-fuseand is what the XDG Portal manages for us.
|
|
||
Comment 20•3 years ago
|
||
(In reply to Alexandre LISSY :gerard-majax from comment #19)
I can manually save there. However when I go to save or download something, the dialog defaults to /run/user/1000/doc/3bd9f0fc/, which is just a temporary folder that contains nothing.
So this is a different issue ?
Well, it "doesn't reliably save to that destination", as in my chosen download directory or the automatically selected directory. I'm not sure if it's a different issue.
- Can you write to
/mnt/itch/Down?
Yes, if I manually select it.
/run/user/1000/doc/3bd9f0fc/is a mount point managed bygvfs-fuseand is what the XDG Portal manages for us.
But it isn't the correct place. What seems to happen is that I can manually chose to download somewhere and it works. But that create a shared "document" according to flatpak:
$ flatpak documents -v --columns=all | grep 3bd
3bd9f0fc /run/user/1000/doc/3bd9f0fc/xxx.pdf org.mozilla.firefox read write grant-permissions
The next download defaults to the containing folder of that document. However it seems that folder isn't a special FUSE mount, just the file. The folder seems to just be a temporary folder, so the new download gets lost.
It seems there are two issues:
- Not defaulting to the download location I have configured.
- Using the containing folder of a download created by the Portal for following downloads.
|
|
||
Comment 21•3 years ago
|
||
BTW I do get an error message in journald:
Jun 22 17:07:03 orac xdg-desktop-por[3213]: Failed to register file:///run/user/1000/doc/11fab5b4/2103.09334.pdf: GDBus.Error:org.freedesktop.portal.Error.InvalidArgument: Invalid fd passed
|
|
||
Comment 22•3 years ago
|
||
Devin, I'm sorry but the situation is really super confusing, can you try and use unambiguous statements?
Well, it "doesn't reliably save to that destination", as in my chosen download directory or the automatically selected directory. I'm not sure if it's a different issue.
I can't tell whether "save" is as "write the file to" or "remember the download directory"
|
|
||
Comment 23•3 years ago
|
||
Both. It doesn't write the file or remember the download directory.
|
|
||
Comment 24•3 years ago
|
||
(In reply to Devin Bayer from comment #23)
Both. It doesn't write the file or remember the download directory.
You just said you were able to write to /mnt/itch/Down ?
Also, I insist but the /run/user/<UID>/doc/<DOCID>/ folder is expected and is what XDG Portal manages for us. You should see it in mount output.
(In reply to Devin Bayer from comment #21)
BTW I do get an error message in journald:
Jun 22 17:07:03 orac xdg-desktop-por[3213]: Failed to register file:///run/user/1000/doc/11fab5b4/2103.09334.pdf: GDBus.Error:org.freedesktop.portal.Error.InvalidArgument: Invalid fd passed
When do you get that ?
Please note I have only focused on Snap package, not on the Flatpak. There might be things different in the ecosystem, I can't tell and I dont have time right now to investigate, and on Ubuntu 22.04 you might be better served by Snap rather than Flatpak.
|
|
||
Comment 25•3 years ago
|
||
(In reply to Alexandre LISSY :gerard-majax from comment #24)
(In reply to Devin Bayer from comment #23)
Both. It doesn't write the file or remember the download directory.
You just said you were able to write to
/mnt/itch/Down?
The first download works, when I manually specify the download directory. The following downloads fail since they try to use the temporary directory created for the first download.
Also, I insist but the
/run/user/<UID>/doc/<DOCID>/folder is expected and is what XDG Portal manages for us. You should see it inmountoutput.
/run/user/<UID>/doc might be expected, but what do you expect <DOCID> to be? It's only valid for one file (the first download), so following downloads will fail.
Jun 22 17:07:03 orac xdg-desktop-por[3213]: Failed to register file:///run/user/1000/doc/11fab5b4/2103.09334.pdf: GDBus.Error:org.freedesktop.portal.Error.InvalidArgument: Invalid fd passedWhen do you get that ?
journald. It's a message from xdg-desktop-portal that happens when FF attempts to download the 2nd file.
Please note I have only focused on Snap package, not on the Flatpak. There might be things different in the ecosystem, I can't tell and I dont have time right now to investigate, and on Ubuntu 22.04 you might be better served by Snap rather than Flatpak.
This bug is about flatpak. I don't use snap.
|
|
||
Comment 26•3 years ago
|
||
(In reply to Devin Bayer from comment #25)
(In reply to Alexandre LISSY :gerard-majax from comment #24)
(In reply to Devin Bayer from comment #23)
Both. It doesn't write the file or remember the download directory.
You just said you were able to write to
/mnt/itch/Down?The first download works, when I manually specify the download directory. The following downloads fail since they try to use the temporary directory created for the first download.
Also, I insist but the
/run/user/<UID>/doc/<DOCID>/folder is expected and is what XDG Portal manages for us. You should see it inmountoutput.
/run/user/<UID>/docmight be expected, but what do you expect<DOCID>to be? It's only valid for one file (the first download), so following downloads will fail.
<DOCID> is something we should not have to care about, it's the xdg ID. I dont know if you can re-use it like you do or if you should go again to your /mnt/itch/Down. It would be useful if you could try several downloads each time manually selecting the correct folder.
Then mabye the real issue is that we keep in memory the XDG's document path instead of the folder you selected ?
Jun 22 17:07:03 orac xdg-desktop-por[3213]: Failed to register file:///run/user/1000/doc/11fab5b4/2103.09334.pdf: GDBus.Error:org.freedesktop.portal.Error.InvalidArgument: Invalid fd passedWhen do you get that ?
journald. It's a message from xdg-desktop-portal that happens when FF attempts to download the 2nd file.
So the second time, thanks.
Please note I have only focused on Snap package, not on the Flatpak. There might be things different in the ecosystem, I can't tell and I dont have time right now to investigate, and on Ubuntu 22.04 you might be better served by Snap rather than Flatpak.
This bug is about flatpak. I don't use snap.
I'm just mentionning that I dont know the status of Flatpak on Ubuntu, and given people of that distro are focusing on Snap, it could very well be that some issues are fixed upstream but not yet in the distro.
|
|
||
Comment 27•3 years ago
|
||
(In reply to Alexandre LISSY :gerard-majax from comment #26)
/run/user/<UID>/docmight be expected, but what do you expect<DOCID>to be? It's only valid for one file (the first download), so following downloads will fail.
<DOCID>is something we should not have to care about, it's the xdg ID. I dont know if you can re-use it like you do or if you should go again to your/mnt/itch/Down. It would be useful if you could try several downloads each time manually selecting the correct folder.
It works every time if I manually select the correct folder. That's what I do for every download.
Then mabye the real issue is that we keep in memory the XDG's document path instead of the folder you selected ?
Yes, that seems like the issue to me.
|
|
||
Comment 28•3 years ago
|
||
Right, filed as https://bugzilla.mozilla.org/show_bug.cgi?id=1775497
Description
•