[snap] Files on local network shares are not opened / written

Steps to reproduce:

1. Run Firefox (version 99.0 or 100.0b9) as a Snap package in Ubuntu 22.04 (upgraded from 21.10)
2. Have a SMB file server available where the network shares can be mounted just by clicking on the share in Nautilus file manager (smb:// protocol, usually mounted dynamically via `/var/run/user/.../gvfs/...`)
3. Have one such share mounted and writable
4. Open any website containing images in Firefox
5. Right-click on an image and select "Save Image As..."
6. In the file save dialog, navigate to the mounted share
7. Assert content of network share is visible and browsable from within the save dialog
8. Select "Save" at any folder in the network share

Actual results:

* File is not saved to selected network share location
* No file download entry is created in "Downloads"
* No error is shown

Expected results:

* File is saved to selected network share location
* No error is shown

Additional information:

* When saving to a folder on the local machine instead, saving works correctly as expected
* In contrast to files, new folders that are created from within the save dialog are saved correctly on the network share

Output of `journalctl -f | grep DEN` when trying to save to the network share is as follows:

```
Mai 04 11:30:18 athlon audit[5959]: AVC apparmor="DENIED" operation="open" profile="snap.firefox.firefox" name="/run/mount/utab" pid=5959 comm="firefox" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
Mai 04 11:30:18 athlon kernel: audit: type=1400 audit(1651656618.225:90): apparmor="DENIED" operation="open" profile="snap.firefox.firefox" name="/run/mount/utab" pid=5959 comm="firefox" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
Mai 04 11:30:18 athlon audit[1151]: USER_AVC pid=1151 uid=103 auid=4294967295 ses=4294967295 subj=? msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/org/freedesktop/hostname1" interface="org.freedesktop.DBus.Properties" member="GetAll" mask="send" name=":1.231" pid=5959 label="snap.firefox.firefox" peer_pid=12048 peer_label="unconfined"
Mai 04 11:30:18 athlon audit[1151]: USER_AVC pid=1151 uid=103 auid=4294967295 ses=4294967295 subj=? msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/org/freedesktop/hostname1" interface="org.freedesktop.DBus.Properties" member="GetAll" mask="send" name=":1.231" pid=5959 label="snap.firefox.firefox" peer_pid=12048 peer_label="unconfined"
Mai 04 11:30:18 athlon audit[1151]: USER_AVC pid=1151 uid=103 auid=4294967295 ses=4294967295 subj=? msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/org/freedesktop/hostname1" interface="org.freedesktop.DBus.Properties" member="GetAll" mask="send" name=":1.231" pid=5959 label="snap.firefox.firefox" peer_pid=12048 peer_label="unconfined"
Mai 04 11:30:18 athlon audit[1151]: USER_AVC pid=1151 uid=103 auid=4294967295 ses=4294967295 subj=? msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/org/freedesktop/hostname1" interface="org.freedesktop.DBus.Properties" member="GetAll" mask="send" name=":1.231" pid=5959 label="snap.firefox.firefox" peer_pid=12048 peer_label="unconfined"
Mai 04 11:30:18 athlon kernel: audit: type=1107 audit(1651656618.313:91): pid=1151 uid=103 auid=4294967295 ses=4294967295 subj=? msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/org/freedesktop/hostname1" interface="org.freedesktop.DBus.Properties" member="GetAll" mask="send" name=":1.231" pid=5959 label="snap.firefox.firefox" peer_pid=12048 peer_label="unconfined"
Mai 04 11:30:18 athlon kernel: audit: type=1107 audit(1651656618.313:93): pid=1151 uid=103 auid=4294967295 ses=4294967295 subj=? msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/org/freedesktop/hostname1" interface="org.freedesktop.DBus.Properties" member="GetAll" mask="send" name=":1.231" pid=5959 label="snap.firefox.firefox" peer_pid=12048 peer_label="unconfined"
Mai 04 11:30:18 athlon kernel: audit: type=1107 audit(1651656618.313:95): pid=1151 uid=103 auid=4294967295 ses=4294967295 subj=? msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/org/freedesktop/hostname1" interface="org.freedesktop.DBus.Properties" member="GetAll" mask="send" name=":1.231" pid=5959 label="snap.firefox.firefox" peer_pid=12048 peer_label="unconfined"
Mai 04 11:30:18 athlon kerne...

For debugging purposes I added and activated the following changes for the Firefox apparmor profile:
```
/run/mount/utab r,
/etc/fstab r,
dbus (send)
    bus=system
    path=/org/freedesktop/hostname1
    interface=org.freedesktop.DBus.Properties
    member=GetAll
    peer=(label=unconfined),
```
Now the apparmor deny messages no longer appear in the journal but saving files to the network share still does not do anything as before.

Thanks for the report Markus. In contrast to saving, does opening files from a network share work within firefox?

Just checked, that's not working either.

To test, I open a new tab, press Ctrl + O to get the "Open File" dialog, browse to the network share and double-click e.g. a .png file. The file dialog then closes and nothing else happens. The image is not opened.

If I do the same steps with an image on the local drive, it opens fine.

In summary, the only thing that works on the network share is creating a new folder from within the "Save" file dialog.

I've set up a samba share on my machine and I can confirm the problem. The share can be browsed, but files on it aren't opened, and there's no user feedback.

I just upgraded Ubuntu from 21.10 to 22.04, and now Chrome (deb), Thunderbird (snap), and FireFox (snap) will not open nor save to any network drives (a home Ubuntu server); all of these apps read/saved to the same server before the upgrade this afternoon. So, "me too", but also it may not be limited to FF, snaps, or even Mozilla, since my Chrome install behaves similarly.

(In reply to Al Savage from comment #6)
> [...] it may not be limited to FF, snaps, or even Mozilla, since my Chrome install behaves similarly.

You are right, this is actually affecting other applications, too. I get the exact same behavior described in the steps to reproduce when using Chromium installed via snap: Local files open fine, opening files on network shares does not trigger any reaction.

Should this issue here remain open?

Created attachment 9275732
Screenshot of Firefox's File|Open dialogue, showing missing remote locations

[snap] Firefox's File|Open dialogue shows missing information in the Location column for Recent files that are non-local.

[.deb] Chrome shows exactly the same behaviour on this workstation.

(I also filed bug 1768492 for the File|Open dialogue resizing 244px larger every time you open it, until it fills the viewport.)

Created attachment 9276133
File pickers comparison 1

I've spun up a fresh 22.04 install in a VM, then run the snap version of ff 100 (on the right) and ff 100 from linux binaries (on the left). The file picker is different between the two versions; the binaries version shows fewer network share aliases, and this binaries version can successfully read and write to network shares.

The snap version's file picker shows aliases for network shares (and a printer) and will navigate into those folders and show files, but when a file is chosen to open, ff does not read the file and does not display an error.

Created attachment 9276134
File pickers comparison 2

In "File pickers comparison 2", I show that the two file pickers (ff run from linux binaries vs the snap package) sort files in a different order, have different options at the bottom, and the bottom window corners are either square or rounded.

The snap's file picker resizes poorly here, as well.

I ran the ff linux binaries version using the suggestion from https://bugzilla.mozilla.org/show_bug.cgi?id=1768500#c5

In the fresh VM, I just installed Chrome (google-chrome) from binaries, and it too uses the troublesome file picker, and has the same issues ("sees" network shares files but does not read them; resizes poorly; window enlarges by 244px both H & V every time it's invoked).

This is a somewhat recent regression, I could do that a few weeks ago.

STR:
 - Mount a CIFS share in GNOME's
 - Right click, "Save link target as"
 - Select a folder within CIFS share where you have credentials

Expected:
 - File is downloaded

Actual:
 - Nothing happens, and no error is reported.

from `journalctl`

```
juin 10 09:33:47 ubuntu-2204-snap xdg-desktop-por[1865]: g_path_get_basename: assertion 'file_name != NULL' failed
juin 10 09:33:47 ubuntu-2204-snap xdg-desktop-por[1865]: g_path_get_dirname: assertion 'file_name != NULL' failed
juin 10 09:33:47 ubuntu-2204-snap xdg-desktop-por[1865]: Failed to register smb://192.168.1.36/documents/Patches/QPdfPresenterConsole-2.7.0-Windows-AMD64.zip: Failed to open smb://192.168.1.36/documents/Patches/QPdfPresenterConsole-2.7.0-Windows-AMD64.zip
```

`Failed to open` comes from https://github.com/flatpak/xdg-desktop-portal/blob/e3ca5567a2dbb5b763a383bba5ff1c0437a7e851/src/documents.c#L91-L92 called from https://github.com/flatpak/xdg-desktop-portal/blob/e3ca5567a2dbb5b763a383bba5ff1c0437a7e851/src/file-chooser.c#L121

From the asserts, it means that somehow `path` ends up `nullptr`: https://github.com/flatpak/xdg-desktop-portal/blob/e3ca5567a2dbb5b763a383bba5ff1c0437a7e851/src/documents.c#L79-L82

```
(gdb) call g_file_get_uri (file)
XDP: No background permissions found: Le d\u00e9lai d\u2019attente est d\u00e9pass\u00e9
$3 = 0x7fffe8008110 "smb://192.168.1.36/documents/Patches/QPdfPresenterConsole-2.7.0-Darwin-x86_64.zip"
(gdb) call g_file_get_uri_scheme (file)
$4 = 0x7fffec00d140 "smb"
(gdb) call g_file_get_path (file)
XDP: Checking background permissions
$5 = 0x0
(gdb)
```

I cant repro the behavior outside of `snap` it seems:
```
#include <stdio.h>
#include <glib.h>
#include <gio/gio.h>

void
print_type (const char* file_uri)
{
        GFile* my_file = g_file_new_for_uri(file_uri);
 char* path = g_file_get_path(my_file);
 fprintf (stdout, "uri:%s => path:%s\n", file_uri, path);
        g_object_unref(my_file);
}

int
main (void)
{
        const char* files[] = {
                "smb://192.168.1.36/documents/Patches/QPdfPresenterConsole-2.7.0-Darwin-x86_64.zip",
        };
        int num_files = sizeof(files)/sizeof(files[0]);
        for(int f = 0; f < num_files; ++f) {
                print_type(files[f]);
        }
        return 0;
}
```

build with
```
gcc gio-test-files.c `pkg-config --cflags --libs glib-2.0 --libs gio-2.0` -o gio-test-files
```

and running:
```
$ ./gio-test-files
uri:smb://192.168.1.36/documents/Patches/QPdfPresenterConsole-2.7.0-Darwin-x86_64.zip => path:/run/user/1000/gvfs/smb-share:server=192.168.1.36,share=documents/Patches/QPdfPresenterConsole-2.7.0-Darwin-x86_64.zip
```

The same code packaged as a snap, installed in `devmode` returns `nullptr` :(

Created attachment 9280651
gio.zip

From https://forum.snapcraft.io/t/interface-suggestion-gvfs/17080/8 there's a similar situation. Indeed, there is no `$SNAP/usr/lib/x86_64-linux-gnu/gio/modules/libgvfsdbus.so` at all. Also, building and running outside of snap and making this `libgvfsdbus.so` unavailable, I can repro, so it's likely because we are missing it?

GIMP fixed it with: https://github.com/snapcrafters/gimp/blob/d4280e0d3f8b88a73501cb778479ee6ec68f5580/desktop-launch/common/desktop-exports#L291-L292

I cannot find where is coming from `snap/command-chain/desktop-launch` on firefox' snap

Ok, it looks like `desktop-launch` comes from third-party dependency. This is really starting to get very snap specific, and gimp has some workaround:
 - https://github.com/snapcrafters/gimp/blob/d4280e0d3f8b88a73501cb778479ee6ec68f5580/snap/snapcraft.yaml#L38-L41
 - https://github.com/snapcrafters/gimp/blob/d4280e0d3f8b88a73501cb778479ee6ec68f5580/desktop-launch/common/desktop-exports#L291-L292

Now, if gimp already has a workaround and we need the same, maybe it's time to do what was asked in https://forum.snapcraft.io/t/interface-suggestion-gvfs/17080/8 and expose the requirements within `gnome-platform` directly ?

(In reply to Alexandre LISSY :gerard-majax from comment #1)
> from `journalctl`
>
> ```
> juin 10 09:33:47 ubuntu-2204-snap xdg-desktop-por[1865]: g_path_get_basename: assertion 'file_name != NULL' failed
> juin 10 09:33:47 ubuntu-2204-snap xdg-desktop-por[1865]: g_path_get_dirname: assertion 'file_name != NULL' failed
> juin 10 09:33:47 ubuntu-2204-snap xdg-desktop-por[1865]: Failed to register smb://192.168.1.36/documents/Patches/QPdfPresenterConsole-2.7.0-Windows-AMD64.zip: Failed to open smb://192.168.1.36/documents/Patches/QPdfPresenterConsole-2.7.0-Windows-AMD64.zip
> ```

Can confirm, seeing this journal entry as well when trying to open an image from an SMB share:
```
Jun 10 18:16:01 mysys xdg-desktop-por[4507]: g_path_get_basename: assertion 'file_name != NULL' failed
Jun 10 18:16:01 mysys xdg-desktop-por[4507]: g_path_get_dirname: assertion 'file_name != NULL' failed
Jun 10 18:16:01 mysys xdg-desktop-por[4507]: Failed to register smb://192.168.1.3/share/image.jpg: Failed to open smb://192.168.1.3/share/image.jpg
```

*** Bug 1767316 has been marked as a duplicate of this bug. ***

(In reply to Alexandre LISSY :gerard-majax from comment #2)
> `Failed to open` comes from https://github.com/flatpak/xdg-desktop-portal/blob/e3ca5567a2dbb5b763a383bba5ff1c0437a7e851/src/documents.c#L91-L92 called from https://github.com/flatpak/xdg-desktop-portal/blob/e3ca5567a2dbb5b763a383bba5ff1c0437a7e851/src/file-chooser.c#L121
>
> From the asserts, it means that somehow `path` ends up `nullptr`: https://github.com/flatpak/xdg-desktop-portal/blob/e3ca5567a2dbb5b763a383bba5ff1c0437a7e851/src/documents.c#L79-L82
>
> ```
> (gdb) call g_file_get_uri (file)
> XDP: No background permissions found: Le d\u00e9lai d\u2019attente est d\u00e9pass\u00e9
> $3 = 0x7fffe8008110 "smb://192.168.1.36/documents/Patches/QPdfPresenterConsole-2.7.0-Darwin-x86_64.zip"
> (gdb) call g_file_get_uri_scheme (file)
> $4 = 0x7fffec00d140 "smb"
> (gdb) call g_file_get_path (file)
> XDP: Checking background permissions
> $5 = 0x0
> (gdb)
> ```

It looks like it is done on purpose: https://github.com/flatpak/xdg-desktop-portal/blob/fe9c5a11a199c966b32f6b7327136782544b845e/src/xdg-desktop-portal.c#L380-L381

So, while using the `smb://` from file picker is blocked and seems not to be hideable for the moment, directly using the mount point should work. if you navigate through the UI via `Other Locations` -> `Computer` -> `/var` -> `run` -> `user` -> `XXX` (your user id) -> `gvfs` −> the directory matching your mountpoint -> then you can access your remote location.

This is working for me. While not optimal, at least you can make use of the remote file server.

The upstream issue tracking being able to perform that operation is https://github.com/flatpak/xdg-desktop-portal/issues/213. Until this is addressed, I believe the UI should not expose mount points it cannot handle, as reported on https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/issues/48

(In reply to Alexandre LISSY :gerard-majax from comment #12)
> So, while using the `smb://` from file picker is blocked and seems not to be hideable for the moment, directly using the mount point should work. if you navigate through the UI via `Other Locations` -> `Computer` -> `/var` -> `run` -> `user` -> `XXX` (your user id) -> `gvfs` −> the directory matching your mountpoint -> then you can access your remote location.
>
> This is working for me. While not optimal, at least you can make use of the remote file server.

Thanks for investigating further! I can confirm that this workaround works for me as well. Not sure why I didn't try that before (see next paragraph).

Unfortunately this entire issue here is yet another sad example for me of a major functionality regression on desktop Linux caused by changes behind the scenes. Going through `/var/run/...` is something that has not been necessary in years with Firefox packaged in APT. And seeing that [this](https://github.com/flatpak/xdg-desktop-portal/issues/213) is already open for four years, I have a feeling we'll see a fix in 2030...

In any case, at least the path forward is clear now.

" if you navigate through the UI via Other Locations -> Computer -> /var -> run -> user -> XXX (your user id) -> gvfs −> the directory matching your mountpoint -> then you can access your remote location."

Via that path, I have no mountpoints listed in the FF picker here.

Created attachment 9281035
Screenshot from 2022-06-13 07-22-50.png

FF snap file picker shows non-functioning mountpoints on left, and none via gvfs on right.

(In reply to Al Savage from comment #16)
> Created attachment 9281035
> Screenshot from 2022-06-13 07-22-50.png
>
> FF snap file picker shows non-functioning mountpoints on left, and none via gvfs on right.

Did you mount these shares e.g. via Nautilus before navigating to the `gvfs` subfolder? If you mount only when the file picker is already showing this folder, the file picker view is not refreshed. Either close the picker then and go to the location again or navigate one folder higher (`1000`) and then back into `gvfs`. You should then see the shares.

If still not, what does running `ls -al /var/run/user/1000/gvfs` in a console print out?

Yes, the shares were/are mounted via Nautilus prior to using FF to attempt to save a file, in that screenshot.

```
asavage@Ubuntu1:~$ ls -al /var/run/user/1000/gvfs
total 0
drwx------ 2 asavage asavage 40 Jun 11 00:20 .
drwx------ 21 asavage asavage 660 Jun 11 08:57 ..
```

I use Nautilus to move files to/from shares without issue, but the file pickers in FF (snap), Thunderbird, and Chrome (deb) all show the shares but cannot work with them.

(In reply to Al Savage from comment #15)
> " if you navigate through the UI via Other Locations -> Computer -> /var -> run -> user -> XXX (your user id) -> gvfs −> the directory matching your mountpoint -> then you can access your remote location."
>
> Via that path, I have no mountpoints listed in the FF picker here.

This is not "Firefox picker", it's the portal one. And if your mountpoints are not visible there, this is another issue, unrelated to Firefox itself.

(In reply to Al Savage from comment #18)
> Yes, the shares were/are mounted via Nautilus prior to using FF to attempt to save a file, in that screenshot.
>
> ```
> asavage@Ubuntu1:~$ ls -al /var/run/user/1000/gvfs
> total 0
> drwx------ 2 asavage asavage 40 Jun 11 00:20 .
> drwx------ 21 asavage asavage 660 Jun 11 08:57 ..
> ```
>
> I use Nautilus to move files to/from shares without issue, but the file pickers in FF (snap), Thunderbird, and Chrome (deb) all show the shares but cannot work with them.

Then your user probably has a different user ID than `1000` (run `echo $UID` or `id` in a terminal and adjust your folder accordingly). I agree with [comment #19](https://bugzilla.mozilla.org/show_bug.cgi?id=1773624#c19) though that this is an unrelated issue.

Just to be clear, when I'm using FF, and choose RMB "Save Image as", that's FF's File Picker. You can call it whatever you like, but from a user perspective, you can't argue it's called something else. I'm a user, not a developer, and I won't cater to your nomenclature whims. If you have misunderstood what I was relating, my apology in advance. I have made considerable effort in both documenting this issue weeks ago, and posting links to the bug in other fora, in an attempt to drive others with the issue to the bug, which you then marked as duplicate because you couldn't bother to search for the existing bug, and decided that your 'discovery' of it was the proper bug-chasing path, instead of marking your newer bug report as a duplicate of the older. I do not appreciate your choice, but because you are actually reading and chasing the issue, I let it be.

You can see in the screenshot fragment above that the shares are shown as mounted in the left pane, in the FF file picker.

```
asavage@Ubuntu1:~$ echo $UID
1000
asavage@Ubuntu1:~$ id
uid=1000(asavage) gid=1000(asavage) groups=1000(asavage),4(adm),7(lp),24(cdrom),27(sudo),29(audio),30(dip),44(video),46(plugdev),110(lxd),114(sambashare),119(lpadmin),128(pulse),129(pulse-access)
```
Again, Nautilus allows use of these mounted shares without issue.

(In reply to Al Savage from comment #21)
> Just to be clear, when I'm using FF, and choose RMB "Save Image as", that's FF's File Picker. You can call it whatever you like, but from a user perspective, you can't argue it's called something else. I'm a user, not a developer, and I won't cater to your nomenclature whims. If you have misunderstood what I was relating, my apology in advance.

It is not "nomenclature whims", there's a very simple problem if it's not our code: we can't fix it, and we depend on upstream to fix and deploy. Even if I could fix the issue myself (which from the discussion I had with people of upstream is non trivial).

> I have made considerable effort in both documenting this issue weeks ago, and posting links to the bug in other fora, in an attempt to drive others with the issue to the bug, which you then marked as duplicate because you couldn't bother to search for the existing bug, and decided that your 'discovery' of it was the proper bug-chasing path, instead of marking your newer bug report as a duplicate of the older. I do not appreciate your choice, but because you are actually reading and chasing the issue, I let it be.

Who said your investigation was useless? I found 4 differents dupes after, because the issue is hitting many people and they were filed differently enough. There's no judgement whatsoever when marking as dupe, I just found it after and I was already working on it.

>
> You can see in the screenshot fragment above that the shares are shown as mounted in the left pane, in the FF file picker.
>
> ```
> asavage@Ubuntu1:~$ echo $UID
> 1000
> asavage@Ubuntu1:~$ id
> uid=1000(asavage) gid=1000(asavage) groups=1000(asavage),4(adm),7(lp),24(cdrom),27(sudo),29(audio),30(dip),44(video),46(plugdev),110(lxd),114(sambashare),119(lpadmin),128(pulse),129(pulse-access)
> ```
> Again, Nautilus allows use of these mounted shares without issue.

Again, there's no code we have direct control over in this file picker. We ask GTK to show one, and GTK under Snap does the job. We dont control anything.

(In reply to Al Savage from comment #18)
> Yes, the shares were/are mounted via Nautilus prior to using FF to attempt to save a file, in that screenshot.
>
> ```
> asavage@Ubuntu1:~$ ls -al /var/run/user/1000/gvfs
> total 0
> drwx------ 2 asavage asavage 40 Jun 11 00:20 .
> drwx------ 21 asavage asavage 660 Jun 11 08:57 ..
> ```
>
> I use Nautilus to move files to/from shares without issue, but the file pickers in FF (snap), Thunderbird, and Chrome (deb) all show the shares but cannot work with them.

So you have nothing in that folder, I dont know why, but it's consistent with the folder being empty within the file picker.

Could you check if you have gvfs-fuse installed? That's the component in charge of creating the local mountpoints

There's a draft PR to fix it

(In reply to Alexandre LISSY :gerard-majax from comment #25)
> There's a draft PR to fix it

I had one weird hiccup, but I cant reproduce anymore, looks like this PR is working and fixing our issue.

If I understand the latest developments on this bug correctly, this has to be fixed in the XDG desktop portal, and [Sergio's PR](https://github.com/flatpak/xdg-desktop-portal/pull/814) is an attempt to do that.

There's also an issue in Firefox where it should be calling `SaveFiles` instead of `SaveFile`. Or is that fixed already?

(In reply to Olivier Tilloy from comment #27)
> If I understand the latest developments on this bug correctly, this has to be fixed in the XDG desktop portal, and [Sergio's PR](https://github.com/flatpak/xdg-desktop-portal/pull/814) is an attempt to do that.

It seems, I dont know when we can expect this to hit your distro.

>
> There's also an issue in Firefox where it should be calling `SaveFiles` instead of `SaveFile`. Or is that fixed already?

This is a separate problem.

Marking this one as P5 because the fix needs to happen in Snap (where there is a proposed patch).

Sergio, do you need me to test the new PR ?

I already tested it and seems to work. Anyway, I'm not sure if they will accept it, so I think that Firefox should also check the received list of URIs and, if it's empty (because the user tried to save into a remote folder), show a more specific error.

Something like "Destination not supported due to security constraints" or something like that.

(In reply to Sergio Costas from comment #31)
> I already tested it and seems to work. Anyway, I'm not sure if they will accept it, so I think that Firefox should also check the received list of URIs and, if it's empty (because the user tried to save into a remote folder), show a more specific error.

Except this is all going through GTK and we dont have such information.

Yes, you are right...

Sergio, I understand you're also waiting, but what can we do to move forward your new PR ? There's no activity so far on it.

Sorry for the delay. We are ATM working on trying to find a solution for that review.

What's the overview of this ? It seems like it would solve a problem of "can't save there" in a general way ?

In which case will it also block saving in locations like '/tmp/' that are not exposed to the Snap host ?

(In reply to tc from comment #37)
> What's the overview of this ? It seems like it would solve a problem of "can't save there" in a general way ?
>

Still blocked on upstream ...

I discovered a simpler way of fixing this. I sent this patch for XDG-desktop-portal-gnome. https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/merge_requests/67

(In reply to Alexandre LISSY :gerard-majax [PTO 12/12/2022-28/02/2023] from comment #38)
> (In reply to tc from comment #37)
> > What's the overview of this ? It seems like it would solve a problem of "can't save there" in a general way ?
> >
>
> Still blocked on upstream ...

Have you tested the new patch?

(In reply to Sergio Costas from comment #40)
> (In reply to Alexandre LISSY :gerard-majax [PTO 12/12/2022-28/02/2023] from comment #38)
> > (In reply to tc from comment #37)
> > > What's the overview of this ? It seems like it would solve a problem of "can't save there" in a general way ?
> > >
> >
> > Still blocked on upstream ...
>
> Have you tested the new patch?

Sorry, I was on leave, is testing the patch still required ?

> > Have you tested the new patch?

> Sorry, I was on leave, is testing the patch still required ?

It would be great if you can test it. In fact, I've been working on it yesterday and today, doing some changes requested by Bastien.

(In reply to Sergio Costas from comment #42)
> > > Have you tested the new patch?
>
> > Sorry, I was on leave, is testing the patch still required ?
>
> It would be great if you can test it. In fact, I've been working on it yesterday and today, doing some changes requested by Bastien.

I'm going to give it a try then.

Sergio, I applied the patch locally on `xdg-desktop-portal-gnome` package, and it is fixing the issue.

(In reply to Alexandre LISSY :gerard-majax from comment #44)
> Sergio, I applied the patch locally on `xdg-desktop-portal-gnome` package, and it is fixing the issue.

Thanks!

Redirect a needinfo that is pending on an inactive user to the triage owner.
:gerard-majax, since the bug has recent activity, could you have a look please?

For more information, please visit [auto_nag documentation](https://wiki.mozilla.org/Release_Management/autonag#inactive_ni_pending.py).

Last activity was three weeks ago, how are we looking wrt a fix?

The patch is sent, but it seems that there were some changes in the maintainers of xdg-desktop-portal-gnome, so I suspect that it will need some time until it is merged upstream... :-(

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Sergio is still actively working on landing this on upstream

That's right. I'm working on landing this on upstream. As commented, the problem is in xdg-desktop-portal-gnome.