Launchpad has imported 35 comments from the remote bug at https://bugzilla.mozilla.org/show_bug.cgi?id=1775497.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2022-06-22T15:56:43+00:00 Lissyx+mozillians wrote: ``` (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/xdg-desktop- portal/+bug/2020655/comments/0 ------------------------------------------------------------------------ On 2022-06-22T15:59:40+00:00 9-dev-p wrote: Thanks! Let me know if you need anymore information. Reply at: https://bugs.launchpad.net/ubuntu/+source/xdg-desktop- portal/+bug/2020655/comments/1 ------------------------------------------------------------------------ On 2022-08-18T15:43:51+00:00 Olivier Tilloy wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/xdg-desktop- portal/+bug/2020655/comments/2 ------------------------------------------------------------------------ On 2022-08-26T08:47:58+00:00 Lissyx+mozillians wrote: *** Bug 1726320 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/xdg-desktop- portal/+bug/2020655/comments/3 ------------------------------------------------------------------------ On 2022-08-29T08:06:43+00:00 9-dev-p wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/xdg-desktop- portal/+bug/2020655/comments/4 ------------------------------------------------------------------------ On 2022-08-29T08:07:39+00:00 9-dev-p wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/xdg-desktop- portal/+bug/2020655/comments/5 ------------------------------------------------------------------------ On 2022-08-29T08:19:45+00:00 From-bugzilla3 wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/xdg-desktop- portal/+bug/2020655/comments/6 ------------------------------------------------------------------------ On 2022-08-29T08:31:22+00:00 9-dev-p wrote: But if I set the path manually in about:config then the first download works. Reply at: https://bugs.launchpad.net/ubuntu/+source/xdg-desktop- portal/+bug/2020655/comments/7 ------------------------------------------------------------------------ On 2022-08-29T08:33:49+00:00 9-dev-p wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/xdg-desktop- portal/+bug/2020655/comments/8 ------------------------------------------------------------------------ On 2022-08-29T08:36:48+00:00 From-bugzilla3 wrote: 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? Reply at: https://bugs.launchpad.net/ubuntu/+source/xdg-desktop- portal/+bug/2020655/comments/9 ------------------------------------------------------------------------ On 2022-08-29T08:40:01+00:00 9-dev-p wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/xdg-desktop- portal/+bug/2020655/comments/10 ------------------------------------------------------------------------ On 2022-08-29T09:08:39+00:00 From-bugzilla3 wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/xdg-desktop- portal/+bug/2020655/comments/11 ------------------------------------------------------------------------ On 2022-08-29T09:09:36+00:00 From-bugzilla3 wrote: Ugh. What is my brain *doing*? "I that" → "I have" Reply at: https://bugs.launchpad.net/ubuntu/+source/xdg-desktop- portal/+bug/2020655/comments/12 ------------------------------------------------------------------------ On 2022-08-29T09:14:13+00:00 9-dev-p wrote: I am using Flatpak 1.12.7-1 from Ubuntu 22.04, with just distro versions, no PPAs. Reply at: https://bugs.launchpad.net/ubuntu/+source/xdg-desktop- portal/+bug/2020655/comments/13 ------------------------------------------------------------------------ On 2022-08-29T09:17:53+00:00 From-bugzilla3 wrote: 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`. Reply at: https://bugs.launchpad.net/ubuntu/+source/xdg-desktop- portal/+bug/2020655/comments/14 ------------------------------------------------------------------------ On 2022-08-29T09:20:00+00:00 9-dev-p wrote: ``` 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 ``` Reply at: https://bugs.launchpad.net/ubuntu/+source/xdg-desktop- portal/+bug/2020655/comments/15 ------------------------------------------------------------------------ On 2022-08-29T09:58:26+00:00 From-bugzilla3 wrote: 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.) Reply at: https://bugs.launchpad.net/ubuntu/+source/xdg-desktop- portal/+bug/2020655/comments/16 ------------------------------------------------------------------------ On 2022-08-29T10:43:19+00:00 9-dev-p wrote: 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 ``` Reply at: https://bugs.launchpad.net/ubuntu/+source/xdg-desktop- portal/+bug/2020655/comments/17 ------------------------------------------------------------------------ On 2022-09-07T20:06:04+00:00 From-bugzilla3 wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/xdg-desktop- portal/+bug/2020655/comments/18 ------------------------------------------------------------------------ On 2022-09-07T20:07:42+00:00 From-bugzilla3 wrote: (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`. Reply at: https://bugs.launchpad.net/ubuntu/+source/xdg-desktop- portal/+bug/2020655/comments/19 ------------------------------------------------------------------------ On 2022-09-08T11:54:02+00:00 9-dev-p wrote: (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`. Reply at: https://bugs.launchpad.net/ubuntu/+source/xdg-desktop- portal/+bug/2020655/comments/20 ------------------------------------------------------------------------ On 2022-09-08T12:05:36+00:00 From-bugzilla3 wrote: (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](https://github.com/flatpak/xdg-desktop-portal/issues/477). (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.) Reply at: https://bugs.launchpad.net/ubuntu/+source/xdg-desktop- portal/+bug/2020655/comments/21 ------------------------------------------------------------------------ On 2022-09-08T12:30:54+00:00 9-dev-p wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/xdg-desktop- portal/+bug/2020655/comments/22 ------------------------------------------------------------------------ On 2022-09-08T12:39:00+00:00 From-bugzilla3 wrote: 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](https://github.com/flatpak/xdg- desktop-portal/issues/463), 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/xdg-desktop- portal/+bug/2020655/comments/23 ------------------------------------------------------------------------ On 2022-09-08T16:13:37+00:00 9-dev-p wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/xdg-desktop- portal/+bug/2020655/comments/24 ------------------------------------------------------------------------ On 2022-10-09T08:16:44+00:00 richardjeco...@protonmail.com wrote: Is there a work around for this please? Whenever I try to download a file now it fails Reply at: https://bugs.launchpad.net/ubuntu/+source/xdg-desktop- portal/+bug/2020655/comments/25 ------------------------------------------------------------------------ On 2023-02-17T10:52:31+00:00 Mozbug444 wrote: > 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/xdg-desktop- portal/+bug/2020655/comments/26 ------------------------------------------------------------------------ On 2023-02-17T11:04:09+00:00 From-bugzilla3 wrote: (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.) Reply at: https://bugs.launchpad.net/ubuntu/+source/xdg-desktop- portal/+bug/2020655/comments/27 ------------------------------------------------------------------------ On 2023-02-17T11:24:06+00:00 Mozbug444 wrote: > 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/xdg-desktop- portal/+bug/2020655/comments/28 ------------------------------------------------------------------------ On 2023-02-17T11:29:08+00:00 Mozbug444 wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/xdg-desktop- portal/+bug/2020655/comments/29 ------------------------------------------------------------------------ On 2023-03-14T15:28:37+00:00 Lissyx+mozillians wrote: (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 ? Reply at: https://bugs.launchpad.net/ubuntu/+source/xdg-desktop- portal/+bug/2020655/comments/30 ------------------------------------------------------------------------ On 2023-05-23T13:37:44+00:00 Lissyx+mozillians wrote: 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 ? Reply at: https://bugs.launchpad.net/ubuntu/+source/xdg-desktop- portal/+bug/2020655/comments/31 ------------------------------------------------------------------------ On 2023-05-23T13:56:52+00:00 Lissyx+mozillians wrote: OK, upstream confirmed this should fix it. Reply at: https://bugs.launchpad.net/ubuntu/+source/xdg-desktop- portal/+bug/2020655/comments/32 ------------------------------------------------------------------------ On 2023-05-23T13:58:01+00:00 Lissyx+mozillians wrote: locally apply https://github.com/flatpak/xdg-desktop-portal/pull/1007 and verify if it fixes as we hope Reply at: https://bugs.launchpad.net/ubuntu/+source/xdg-desktop- portal/+bug/2020655/comments/33 ------------------------------------------------------------------------ On 2023-05-24T10:08:51+00:00 Lissyx+mozillians wrote: Locally rebuilding xdg-desktop-portal package on 22.04 and it works. Reply at: https://bugs.launchpad.net/ubuntu/+source/xdg-desktop- portal/+bug/2020655/comments/34 ** Changed in: firefox-snap Status: Unknown => Confirmed ** Bug watch added: github.com/flatpak/xdg-desktop-portal/issues #477 https://github.com/flatpak/xdg-desktop-portal/issues/477 ** Bug watch added: github.com/flatpak/xdg-desktop-portal/issues #463 https://github.com/flatpak/xdg-desktop-portal/issues/463 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to xdg-desktop-portal in Ubuntu. https://bugs.launchpad.net/bugs/2020655 Title: XDG Desktop Portal should show "nice" user path Status in firefox snap: Confirmed Status in xdg-desktop-portal: Unknown Status in xdg-desktop-portal package in Ubuntu: New Bug description: Users hould not see "/run/xxx" but rather e.g., "/tmp/" To manage notifications about this bug go to: https://bugs.launchpad.net/firefox-snap/+bug/2020655/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
