Closed Bug 1775497 Opened 2 years ago Closed 6 months ago

[Flatpak] [Snap] Do not remember download directory as XDG Document portal directory but user-selected directory

Categories

(Firefox Build System :: Third Party Packaging, defect, P5)

Product:
Firefox Build System
Component:
Third Party Packaging
Platform:
All
Linux
Type:
defect

Tracking

(firefox103 affected)

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
firefox103 --- affected

People

(Reporter: gerard-majax, Assigned: gerard-majax)

References

(Blocks 3 open bugs)

Details

(In reply to Alexandre LISSY :gerard-majax from comment #26)

        /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.

    <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.

As much as I could understand so far of our interactions there, we delegate handling of the file picker to GTK, and we have no direct notion of the "original good" path that users might expect (e.g, smb://server/share/Path) and what we get back from the file picker has been processed by the XDG portal and we only get the Portal's Document folder, i.e., /run/user/<UID>/doc/<DOCID>/. I dont know how much we can fix there.

Summary: [Flatpak] [Snap] → [Flatpak] [Snap] Do not remember download directory as XDG Document portal directory but user-selected directory

Thanks! Let me know if you need anymore information.

This appears to be affecting the firefox snap on Ubuntu 20.04, but not on Ubuntu 22.04 (see https://forum.snapcraft.io/t/firefox-v-101-0-2-download-directory-always-changes-to-run-user-1000-doc/30395). So the version of the document portal plays a role.

Blocks: snap-download

(In reply to Olivier Tilloy from comment #2)

This appears to be affecting the firefox snap on Ubuntu 20.04, but not on Ubuntu 22.04 (see https://forum.snapcraft.io/t/firefox-v-101-0-2-download-directory-always-changes-to-run-user-1000-doc/30395). So the version of the document portal plays a role.

I see this behavior on 22.04.

(In reply to Alexandre LISSY :gerard-majax from comment #0)

As much as I could understand so far of our interactions there, we delegate handling of the file picker to GTK, and we have no direct notion of the "original good" path that users might expect (e.g, smb://server/share/Path) and what we get back from the file picker has been processed by the XDG portal and we only get the Portal's Document folder, i.e., /run/user/<UID>/doc/<DOCID>/. I dont know how much we can fix there.

FF does know the original good path, because I can enter it manually in about:config. But it doesn't use it for subsequent downloads.

(In reply to Devin Bayer from comment #5)

FF does know the original good path, because I can enter it manually in about:config. But it doesn't use it for subsequent downloads.

That's not how it works. If I understand the portal's D-Bus docs correctly, what you set in about:config goes into the portal via the current_folder argument, then the portal returns a /run/user/<UID>/ path and, because it'd leak information to a potential attacker for a program to be able to recover the un-sandboxed path from the sandboxed one, Firefox has no choice but to assume that you changed the directory from the one it remembers and save the new one.

I can't remember whether a PR has been accepted, but there's been discussion on the xdg-desktop-portal bug tracker around having the file picker do that conversion so apps like Firefox still only see the sandboxed path, but the picker dialogs pretend that only un-sandboxed paths are ever being used, so the user never needs to know that the sandboxed paths exist.

But if I set the path manually in about:config then the first download works.

The way FF should do it, is use the configured path for each download. Yes, it gets translated to a new path via the portal - that's fine. But that path will only be valid for a single document.

Sure. As long as Firefox is configured so that, no matter what you do in the file chooser, it always resets to the about:config-specified folder the next time, that'd make sense... but then why not just use Flatseal to whitelist that folder so that Firefox sees the un-sandboxed path?

I do have it whitelisted but that has no effect. The problem is that when I download something, FF uses the download dialog to create a portal doc path which is only valid for that one file. Then it saves that path in browser.download.lastDir and tries to use it for subsequent downloads. Those downloads silently fail.

Strange. I only get that behaviour for un-whitelisted paths.

Are you using Snap or Flatpak? Are you using the distro version or a newer version via a PPA? I'm on Kubuntu 20.04, running Flatpak via the PPA referenced via from Flathub's setup instructions and I that updated versions of various components including the backend and GTK frontend for the portal host.

Ugh. What is my brain doing? "I that" → "I have"

I am using Flatpak 1.12.7-1 from Ubuntu 22.04, with just distro versions, no PPAs.

I've got 1.12.7-1flatpak1~20.04 of flatpak from the PPA, but I'd be more interested in what version of xdg-desktop-portal you have. The PPA is giving me 1.8.1-1~flatpak1~20.04.

ii  libportal-gtk3-1:amd64                            0.6-2                                        amd64        Flatpak portal library for GTK 3 GUIs
ii  libportal1:amd64                                  0.6-2                                        amd64        Flatpak portal library - non-GUI part
ii  xdg-desktop-portal                                1.14.4-1ubuntu2~22.04.1                      amd64        desktop integration portal for Flatpak and Snap
ii  xdg-desktop-portal-gtk                            1.14.0-1build1                               amd64        GTK+/GNOME portal backend for xdg-desktop-portal
ii  xdg-desktop-portal-kde                            5.24.4-0ubuntu1                              amd64        backend implementation for xdg-desktop-portal using Qt
ii  xdg-desktop-portal-wlr                            0.5.0-3                                      amd64        xdg-desktop-portal backend for wlroots

Hmm. Two other questions come to mind, based on my hazy memories of sticking points on my system.

  1. Can you find the folder in question inside flatpak run --command=bash org.mozilla.firefox? Some paths, such as /usr get overlayed by the Flatpak runtime system and whitelisting them gets ignored. (Something I learned while trying to get integration to work between Flatpak'd Blender and PPA'd MakeHuman. MakeHuman's hot reload protocol assumes that Blender will have the same view of /usr/share/makehuman-community/data that it does.
  2. Do any of the paths contain symlinks? (I can't remember whether Flatpak had this problem, but Firejail's whitelist directives fail pretty silently if you've done something like symlinking /srv to /mnt/Seagate_10TB/srv or ~/.PlayOnLinux to /mnt/Seagate_10TB/tier3/PlayOnLinux and didn't remember to whitelist the resolved version too.)

Yes I do see it, it's outside /usr and contains no symlinks:

[12:36:39] flatpak run --command=bash org.mozilla.firefox -c 'ls -dl /mnt/itch/Down'
drwx------ 3 dev dev 20 Aug 29 09:52 /mnt/itch/Down

(In reply to Devin Bayer from comment #17)

Yes I do see it, it's outside /usr and contains no symlinks:

[12:36:39] flatpak run --command=bash org.mozilla.firefox -c 'ls -dl /mnt/itch/Down'
drwx------ 3 dev dev 20 Aug 29 09:52 /mnt/itch/Down

Sorry for going silent for a week.

What does zenity --file-selection --save output when you pick your paths? If it outputs the non-portal versions, the problem is in Firefox. If it outputs the portal versions, then the problem is in your portal host or sandbox configuration.

(In reply to Stephan Sokolow from comment #18)

What does zenity --file-selection --save output when you pick your paths? If it outputs the non-portal versions, the problem is in Firefox. If it outputs the portal versions, then the problem is in your portal host or sandbox configuration.

Sorry. Forgot to clarify. zenity is available in the runtime the org.mozilla.firefox Flatpak depends on and uses GtkFileChooserNative under the hood, so I'm asking what it outputs when you run it inside flatpak run --command=bash org.mozilla.firefox.

(In reply to Stephan Sokolow from comment #19)

What does zenity --file-selection --save output when you pick your paths? If it outputs the non-portal versions, the problem is in Firefox. If it outputs the portal versions, then the problem is in your portal host or sandbox configuration.

That gives me a portal path in the firefox flatpak. However in other flatpaks with the same filesystem overrides, even those using the same Freedesktop Platform, it gives me the real path.

I think this isn't the main issue though – I shouldn't have to add my download directory to my filesystem permission override. If I use the file selection box in Preferences to select my download directory, I get a portal path. And that path works for downloads. It's only the 2nd and following download that fail, because FF tries to use the document specific path that it saved in browser.download.lastDir.

(In reply to Devin Bayer from comment #20)

I think this isn't the main issue though – I shouldn't have to add my download directory to my filesystem permission override. If I use the file selection box in Preferences to select my download directory, I get a portal path. And that path works for downloads. It's only the 2nd and following download that fail, because FF tries to use the document specific path that it saved in browser.download.lastDir.

Ahh. Now I understand. You're describing the open bug, flatpak/xdg-desktop-portal#477: Open file chooser in folder containing specific file.

(Which is a terribly vague-sounding title but is basically requesting that Documents Portal paths be guaranteed to remain unique to a specific permissions grant if you strip off a single path component to get the parent/containing directory, and that the File Chooser portal be guaranteed to reverse the transformation and display the actual un-sandboxed path if given one of them as the starting location.)

That sounds like it might make it work because I think the issue only occurs when a file selection dialog box is opened. Though that issue has been open for 2 years, it doesn't seem like they consider it the right way to use the API as it currently exists.

It's a necessary way to support if they want to support the apparent design goal of allowing the backend of things like GtkFileChooserNative and QFileDialog to be transparently swapped out, and I can't think of any simpler way to achieve the desired user experience.

Also, Mikenux (the only person who proposed an alternative approach) isn't part of the development team. He lacks the contributor badge and, from our conversations on flatpak/xdg-desktop-portal#463: Portal to open file and neighbouring files, he's an enthusiastic novice in this space, who leans toward preferring security over convenience to a sometimes impractical degree.

I think it's more like the bugs here that have been open for 12+ years, where they're agreed to be desirable, but no regular has the time to fix them and no volunteer has stepped up to take responsibility for it.

As an aside, I did figure out why my filesystem permission override wasn't working with FF – the override only worked when set with sudo and not on the user installation. The flatpak info --show-permissions output merges them, which is pretty misleading.

I think the best user experience currently achievable is just to always default to the configured download directory and not the last one, at least if it's a portal directory.

Is there a work around for this please? Whenever I try to download a file now it fails

Severity: -- → S4
Component: Widget: Gtk → Third Party Packaging
Priority: -- → P5
Product: Core → Firefox Build System

I think the best user experience currently achievable is just to always default to the configured download directory and not the last one, at least if it's a portal directory.

This is not true if, say, the user is saving N images from current web page to directory D. If directory D is not remembered, the user has to navigate to it again for each image.

As Flatpaks, FF 110 does not remember last-saved-to directory, but ungoogled-chromium 110 browser and Akregator 5.22 feed reader DO remember last-saved-to directory. Please change FF to remember last-saved-to directory.

(In reply to Bill Dietrich from comment #26)

As Flatpaks, FF 110 does not remember last-saved-to directory, but ungoogled-chromium 110 browser and Akregator 5.22 feed reader DO remember last-saved-to directory. Please change FF to remember last-saved-to directory.

As an alternative voice, please don't break "remember saved-to directory on a per-site basis" for those of us who rely on it and are OK with setting Flatpak manifest permission grants for ths relevant locations to make it work.

This is an XDG File Chooser Portal bug.

(Specifically, the file chooser's get path and set path operations are asymmetric. If the user sets path A and it gets converted to document portal path B on retrieval, then Firefox handing path B back in will not cause the chooser to navigate to path A.)

OK with setting Flatpak manifest permission grants for the relevant locations to make it work

You may be right, it may be a permissions issue. Saving to local disk seems to remember last-saved, saving to a mounted LUKS volume does not.

After adding "All System Files" permission to FF in Flatseal, when trying to save to a mounted LUKS volume, the last-saved-to directory apparently is remembered, but actually trying to save a file to it fails silently.

See Also: → 1815043
See Also: 1815043 → 1799381

(In reply to Stephan Sokolow from comment #27)

(In reply to Bill Dietrich from comment #26)

As Flatpaks, FF 110 does not remember last-saved-to directory, but ungoogled-chromium 110 browser and Akregator 5.22 feed reader DO remember last-saved-to directory. Please change FF to remember last-saved-to directory.

As an alternative voice, please don't break "remember saved-to directory on a per-site basis" for those of us who rely on it and are OK with setting Flatpak manifest permission grants for ths relevant locations to make it work.

This is an XDG File Chooser Portal bug.

(Specifically, the file chooser's get path and set path operations are asymmetric. If the user sets path A and it gets converted to document portal path B on retrieval, then Firefox handing path B back in will not cause the chooser to navigate to path A.)

Stephan, do you have an upstream issue to track that? I saw https://github.com/flatpak/xdg-desktop-portal/issues/973 ?

Flags: needinfo?(from_bugzilla3)

Amin, do you know if we could RESOLVED:FIXED the present bug in light of https://github.com/flatpak/xdg-desktop-portal/issues/973#issuecomment-1559382416 ?

Flags: needinfo?(bandali)

OK, upstream confirmed this should fix it.

Flags: needinfo?(bandali)
Flags: needinfo?(from_bugzilla3)

locally apply https://github.com/flatpak/xdg-desktop-portal/pull/1007 and verify if it fixes as we hope

Flags: needinfo?(lissyx+mozillians)

Locally rebuilding xdg-desktop-portal package on 22.04 and it works.

Flags: needinfo?(lissyx+mozillians)

Please check the xdg-desktop-portal version. In xdg-desktop-portal 1.18.0 and later this problem should be fixed. Please reopen if you still see the problem.

Status: NEW → RESOLVED
Closed: 6 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.