User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:101.0) Gecko/20100101 Firefox/101.0

Steps to reproduce:

I installed the patch https://github.com/flatpak/xdg-desktop-portal/pull/814#issuecomment-1157405216 for Desktop Portal to allow to access elements in GVfs-mounted devices, launched Firefox in Ubuntu 22.04 (thus, the SNAP version), and tried to save a web page with all its contents in a remote SFTP unit mounted using GVfs (see screenshot #1).

Actual results:

The operation failed (see screenshot #2). But if I press the "Retry" arrow, it now succeeds (screenshot #3), but only stores the .html file, without the pictures and other elements (screenshot #4).

Thanks to some debugging that I added in the XDG-Desktop-Portal code, I detected that, when storing the webpage, Firefox uses "SaveFile", when, since it is storing several files (the .html file and the folder with all the other components), it should use "SaveFiles".

Expected results:

Firefox should have stored the .html file and a folder with all the other page elements (like pictures, CSS...).

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

I can clearly repro on a nightly.

Sergio, can you confirm it is working when you save to a local directory, and you only hit that on a remote share? I repro on a SMB one.

If I save it in my desktop (and, thus, directly in my hard disk) it works fine. It seems to fail only when it has to do a translation from a remote URI into a FUSE-mounted folder.

BTW: I'm using the stable SNAP. If you want me to try with a nightly build, please, tell me where I can download it? (is it enough to use --edge?)

(In reply to Sergio Costas from comment #8)

BTW: I'm using the stable SNAP. If you want me to try with a nightly build, please, tell me where I can download it? (is it enough to use --edge?)

--edge should be enough if you need it

Ok, so on a pure Wayland but not Snap build, I can repro the behavior as well when saving to a local folder ?! Download is marked as "Failed" yet the files and the folder are there ...

I installed the --edge version, but still happens the same: saving the page in a remote folder fails, it is marked as "Failed", and the remote folder is empty. Clicking on the circular arrow to "Retry" does store the page, but without the folder with the contents (images, CSS...)

(In reply to Sergio Costas from comment #11)

I installed the --edge version, but still happens the same: saving the page in a remote folder fails, it is marked as "Failed", and the remote folder is empty. Clicking on the circular arrow to "Retry" does store the page, but without the folder with the contents (images, CSS...)

FTR, given that in both local and remote case it seems to call SaveFile, I am unsure whether that is the root of the issue.

Well, IMHO, SaveFile should fail in all cases because Firefox is saying "I want to store just this file here", and after that, it also creates a folder in the same path, which, AFAIK, isn't what SaveFile neither was designed for, nor should allow to do... In fact, I presume that's the reason why SaveFiles does exist. In my opinion, this seems more like a "fortunate bug" in xdg-desktop-portal...

(In reply to Sergio Costas from comment #13)

Well, IMHO, SaveFile should fail in all cases because Firefox is saying "I want to store just this file here", and after that, it also creates a folder in the same path, which, AFAIK, isn't what SaveFile neither was designed for, nor should allow to do... In fact, I presume that's the reason why SaveFiles does exist. In my opinion, this seems more like a "fortunate bug" in xdg-desktop-portal...

Ok. While I can repro on a shipped nightly, I can't repro on either a local debug or opt build. That's going to be tricky.

Mmm... Do you mean that you can't reproduce it while accessing a SMB/SFTP remote folder using my patch?

(also, my comment is only an opinion, of course... I'm not an expert in portals).

(In reply to Sergio Costas from comment #15)

Mmm... Do you mean that you can't reproduce it while accessing a SMB/SFTP remote folder using my patch?

(also, my comment is only an opinion, of course... I'm not an expert in portals).

No, it's even worse: I repro the behavior on a nightly from Mozilla (i.e., my daily browser) pure Wayland / Ubuntu 22.04, outside of Snap. But I can't repro when I test with builds I do myself. Wondering if there's a race condition and we're triggering it easily on a PGO build ?

Mmm... that's odd, because outside a snap, AFAIK, there should be no problems and it should work fine...

(In reply to Sergio Costas from comment #17)

Mmm... that's odd, because outside a snap, AFAIK, there should be no problems and it should work fine...

Yes. FTR, I have made a test here to check the calls:

• /usr/libexec/xdg-desktop-portal -rv
• /usr/libexec/xdg-desktop-portal-gtk -rv
• /usr/libexec/xdg-desktop-portal-gnome -rv

All three at the same time.

• nightly from mozilla, reproducing the issue: 0 mention of SaveFile on all three processes above
• nightly from me, not reproducing the issue: 0 mention of SaveFile on all three processes above

So my current analysis is that I need to see how the code that performs packing of the page works, as :gijs suggested, because I dont think it's related in how we perform the writing itself.

Ok, I could reproduce on my own profile, running nightly within rr. The trace is 92GB but I hope to be able to investigate more from there.

(In reply to Sergio Costas from comment #17)

Mmm... that's odd, because outside a snap, AFAIK, there should be no problems and it should work fine...

I just discovered there's another explanation for my failure on opt build: bug 1445211. Local debug build, uBlock Origin installed and enabled, I repro. Disable it, I dont repro.

So maybe after all we're back to SaveFile vs SaveFiles ...

Well, in my case, my Firefox is completely clean: it has no extensions installed.

(In reply to Sergio Costas from comment #21)

Well, in my case, my Firefox is completely clean: it has no extensions installed.

This is what I am saying: what I expected to be the same issue is unrelated, and we might still have a bug on how we perform the saving call via xdg portal

Oh, ok... sorry. I was reading bug 1445211 and was a little confused. Yes, I fully agree with you.

No bug when "Only HTML". Still trying to find where the SaveFile call happens, I fear it is within GTK ...

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

No bug when "Only HTML".

It makes sense, since only one file is being saved.

Still trying to find where the SaveFile call happens, I fear it is within GTK ...

Can't help there, I'm not familiar enough with Firefox code. All what I could try was a search in the source code for "modeSave", in the hope that those points were the possible calls to Xdg-desktop-portal.

(In reply to Sergio Costas from comment #25)

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

No bug when "Only HTML".

It makes sense, since only one file is being saved.

Still trying to find where the SaveFile call happens, I fear it is within GTK ...

Can't help there, I'm not familiar enough with Firefox code. All what I could try was a search in the source code for "modeSave", in the hope that those points were the possible calls to Xdg-desktop-portal.

So we call GTK from https://searchfox.org/mozilla-central/rev/d3c2f51d89c3ca008ff0cb5a057e77ccd973443e/widget/gtk/nsFilePicker.cpp#587-594 and this ends up in https://gitlab.gnome.org/GNOME/gtk/-/blob/3ea8dc02a3260a0e3220bea6abd7e854b639f14e/gtk/gtkfilechoosernativeportal.c#L484-485

Unfortunately, it seems to only provide SaveFile ...

Mmm... you are right...

But what is odd is that GTK_FILE_CHOOSER_ACTION_SELECT_FOLDER should be related with SaveFiles, but instead it calls OpenFile... that is quite odd...

Maybe a bug...?

I know nothing about GTK/Portals, so I'm not really at ease to make a judgement call.

Really is more about Gtk FileChooser API: https://valadoc.org/gtk+-3.0/Gtk.FileChooser.html and the possible actions for it: https://valadoc.org/gtk+-3.0/Gtk.FileChooserAction.html

I'll ask in discourse...

Ok, I hadn't to ask, just check the Xdg-Desktop-Portal documentation https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.FileChooser . In the OpenFile method there is this note:

directory b
    Whether to select for folders instead of files. Default is to select files. This option was added in version 3. 

So it isn't a bug in Gtk3.

(In reply to Sergio Costas from comment #32)

Ok, I hadn't to ask, just check the Xdg-Desktop-Portal documentation https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.FileChooser . In the OpenFile method there is this note:

directory b
    Whether to select for folders instead of files. Default is to select files. This option was added in version 3. 

So it isn't a bug in Gtk3.

I'm sorry but you are confusing me now.

Sorry, it wasn't my intention. I mean that it is correct that GTK3 calls to OpenFile to choose a folder. And that means that you are right: it seems that GTK3 doesn't allow to call the SaveFiles method of the portal.

Could it be very complex to store the page in a single HTML file? I mean, inserting the images inside in base64 format and so on... (although maybe you have reasons to store it in a separate folder).

(In reply to Sergio Costas from comment #35)

Could it be very complex to store the page in a single HTML file? I mean, inserting the images inside in base64 format and so on... (although maybe you have reasons to store it in a separate folder).

There is already that option ? Hard to discover I feel, but when you have the dialog, bottom right you can select

I tried that option but doesn't work, it just stores the HTML.

What I mean is that a way of avoid this problem would be to modify the way Firefox stores the pages, so instead of storing the HTML in a file, and all the other files (pictures, CSS and so on) in a folder, and require both to show the page, make it to store everything in a single HTML file, like this extension does: https://addons.mozilla.org/es/firefox/addon/single-file/

But, of course, it isn't something trivial...

So we get into https://searchfox.org/mozilla-central/rev/d3c2f51d89c3ca008ff0cb5a057e77ccd973443e/toolkit/content/contentAreaUtils.js#107 and later hit https://searchfox.org/mozilla-central/rev/d3c2f51d89c3ca008ff0cb5a057e77ccd973443e/toolkit/content/contentAreaUtils.js#705

The docs on XDG are not super crystal clear regarding the difference between SaveFile and SaveFiles. Also, the implem is ... well, it calls a xdp_impl_file_chooser_complete_save_files but I cannot find its implementation.

What I understand is that with "SaveFile" you pass a single file name and the portal asks the user where to store it and whether to change the name; and if a file with that name already exists, asks the user what to do (overwrite, rename, fail); finally it returns the full path that you can use to store a single file. Meanwhile, with "SaveFiles" you pass several file names and the portal asks the user a folder where to store all those files. The portal also checks if any of those filenames already exists and decide what to do to avoid clashing (like renaming them), and finally returns the final list of paths, one for each filename.

That's what I understand from the standard... But certainly it isn't very useful for this case.

But I dont see anything from reading code that would change how the files are actually wrote. Is this the portal that perform actual write() call at the end of the chain, or is this firefox?

As far as I understand the standard, the portal only sends you a list of paths, and you do the open(), write() and close() calls. But again, I never worked directly with them.

Ok, I've managed to get some debug within snap.

My remove share is mounted and accessible locally via /run/user/1000/gvfs/smb-share\:server\=192.168.1.36\,share\=documents/.

From https://searchfox.org/mozilla-central/rev/d3c2f51d89c3ca008ff0cb5a057e77ccd973443e/browser/components/downloads/DownloadsCommon.jsm#300 I can see failures reporting access denied.

The target object is weird: path: "/run/user/1000/doc/8fc18b34/..." but is writable from shell and it looks like it acts as a temp folder. I am starting to wonder if your draft is enough or might be missing some bits ?

XDP: Handling SaveFile
XDP: convert uri file:///run/user/1000/gvfs/smb-share:server=192.168.1.36,share=documents/Patches/Toto/....html -> file:///run/user/1000/doc/8fc18b34/....html

That's the point: GVfs uses FUSE to make the remote share appear locally like normal files in the hard drive (or SSD :-D ), but an snap or flatpak application shouldn't be allowed to directly access those files, so what the portal does is to "link" only that file inside the container, and passes the "translated" path to the contained program. That's why you see that weird path, because that path is only valid inside the container, and any access from inside the container to that path is mapped by the kernel to the original file.

I'm not sure if I explained it right...

What I mean is that when the user chooses in the portal, let's say, file:///run/user/1000/gvfs/smb-share:server=192.168.1.36,share=documents/Patches/Toto/index.html, the portal creates a "link" inside the container that points to that specific file, let's say /run/user/1000/doc/8fc18b34/index.html, and now the program inside the container can access the file that the user chose, but can't read other files, no mattering if they are in the same folder than the one that the user asked.

(In reply to Sergio Costas from comment #47)

What I mean is that when the user chooses in the portal, let's say, file:///run/user/1000/gvfs/smb-share:server=192.168.1.36,share=documents/Patches/Toto/index.html, the portal creates a "link" inside the container that points to that specific file, let's say /run/user/1000/doc/8fc18b34/index.html, and now the program inside the container can access the file that the user chose, but can't read other files, no mattering if they are in the same folder than the one that the user asked.

No that was clear and that was my understanding as well, but is writable from shell and it looks like it acts as a temp folder

My point being, Firefox still gets access denied there, so I'm wondering WHY since I can access it from the shell. Race ?

Mmm... then I don't understand...

(In reply to Sergio Costas from comment #49)

Mmm... then I don't understand...

Bingo!

$ grep "8fc18b34" strace/firefox.1* | grep EPERM
strace/firefox.15759:mkdir("/run/user/1000/doc/8fc18b34/xxx_fichiers", 0755) = -1 EPERM (Op\u00e9ration non permise)

And from shell:

$ LC_ALL=C mkdir /run/user/1000/doc/8fc18b34/test
mkdir: cannot create directory '/run/user/1000/doc/8fc18b34/test': Operation not permitted

Do you know what manages permissions there? I dont see anything in journalctl

I have no idea, sorry. What I know is that it makes sense that a "normal" program couldn't access the '/run/user/1000/doc...' zone directly. In fact, that folder is a FUSE drive controlled directly by the portal (just do a "mount |grep 1000"), so it makes sense that you have no direct access: I suspect that all those files are completely virtual and created "on the fly".

(In reply to Sergio Costas from comment #52)

I have no idea, sorry. What I know is that it makes sense that a "normal" program couldn't access the '/run/user/1000/doc...' zone directly. In fact, that folder is a FUSE drive controlled directly by the portal (just do a "mount |grep 1000"), so it makes sense that you have no direct access: I suspect that all those files are completely virtual and created "on the fly".

No, I do have access to that correctly: I can create files, but not directories. Here is log of xdg-document-portal:

XDP: LOOKUP 4:test
XDP: LOOKUP -> error ENOENT
XDP: CREATE 4 test WRONLY,NONBLOCK,CREAT, 0100664
XDP: CREATE -> error 95
XDP: LOOKUP 4:test
XDP: LOOKUP 4:test => fb6ffec378c367fd
XDP: SETATTR fb6ffec378c367fd ATIME,MTIME,ATIME_NOW,MTIME_NOW
XDP: LOOKUP 4:test.dir
XDP: LOOKUP -> error ENOENT
XDP: MKDIR 4 test.dir
XDP: MKDIR -> error EPERM

And here is what I was doing:

user@ubuntu-2204-snap:~$ touch /run/user/1000/doc/6792356a/test
user@ubuntu-2204-snap:~$ mkdir /run/user/1000/doc/6792356a/test.dir
mkdir: impossible de cr\u00e9er le r\u00e9pertoire \u00ab/run/user/1000/doc/6792356a/test.dir\u00bb: Op\u00e9ration non permise
user@ubuntu-2204-snap:~$ 

And the mount output:

portal on /run/user/1000/doc type fuse.portal (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)

This is where we hit EPERM: https://github.com/flatpak/xdg-desktop-portal/blob/fe9c5a11a199c966b32f6b7327136782544b845e/document-portal/document-portal-fuse.c#L1292-L1296

Sergio, I'm getting lost on how the XDG document part works, but it more and more looks like the issue is over there. I'm stopping for today, hopefully you can find more about why we get this EPERM

I suspect that, although the standard doesn't explicitly says it, the code only allows to create regular files, not folders...

I think that you should ask in the XDG forum.

(In reply to Sergio Costas from comment #56)

I suspect that, although the standard doesn't explicitly says it, the code only allows to create regular files, not folders...

I think that you should ask in the XDG forum.

I fear you are both right and wrong. It looks like SaveFile will trigger XDG Document Portal related code that allows to create files into the folder presented, and we get into there via https://github.com/flatpak/xdg-desktop-portal/blob/13e8307791bbd549cc882b4e368032ad8f53536d/document-portal/document-portal.c#L924-L928

Unfortunately, we get there for only the HTML file we are saving. On our side, internalSave presents a file picker https://searchfox.org/mozilla-central/rev/cc98a15c7327d742d283cddddde712a8a3165006/toolkit/content/contentAreaUtils.js#333-344 and then continue using the path it has received as valid and we get to internalPersist: https://searchfox.org/mozilla-central/rev/cc98a15c7327d742d283cddddde712a8a3165006/toolkit/content/contentAreaUtils.js#380-397

Later, this builds a nsITransfer: https://searchfox.org/mozilla-central/rev/cc98a15c7327d742d283cddddde712a8a3165006/toolkit/content/contentAreaUtils.js#456-471 and then defers the actual download and writing of content to this nsITransfer coupled with https://searchfox.org/mozilla-central/rev/cc98a15c7327d742d283cddddde712a8a3165006/dom/webbrowserpersist/nsWebBrowserPersist.cpp#1542

It means that the portal authorized creation of the HTML file and our code assumes it can use the same parent directory to create a subdirectory containing the resources.

I am not sure we are able to use SaveFiles there as well: first because it's GTK that initiates this part, second because I am unsure we have the full list of files we want to allow saving. I've been able to hack a few lines of python with dbus to perform portal operations, and I am going to test if under the assumption that we can get a full list of resources, passing via SaveFiles would allow us to create all of them.

I suspect that the only way of really fixing this is to embed all the data into the HTML document and save everything as a single file, like this extension does (https://addons.mozilla.org/es/firefox/addon/single-file/ ), but it isn't an easy-to-implement feature...

Sergo, this is what I put together with SaveFile but I cant get the proper path. Whenever I run this code, I get

f /run/user/1000/gvfs/smb-share:server=nas,share=documents/Patches/Toto/toto.html

While I would expect:

f /run/user/1000/doc/<ID>/Patches/Toto/toto.html

I suspect it could be because of xdp_app_info_is_host https://github.com/flatpak/xdg-desktop-portal/blob/9f03bab1d96a0e87fecd68f24a7045e62e02c0c1/src/file-chooser.c#L118-L121 ?

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

Created attachment 9282231 [details]
python dbus test

Sergo, this is what I put together with SaveFile but I cant get the proper path. Whenever I run this code, I get

f /run/user/1000/gvfs/smb-share:server=nas,share=documents/Patches/Toto/toto.html

While I would expect:

f /run/user/1000/doc/<ID>/Patches/Toto/toto.html

I suspect it could be because of xdp_app_info_is_host https://github.com/flatpak/xdg-desktop-portal/blob/9f03bab1d96a0e87fecd68f24a7045e62e02c0c1/src/file-chooser.c#L118-L121 ?

Are you running this from inside a container? If not, then there is no reason to translate the URIs.

(In reply to Sergio Costas from comment #60)

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

Created attachment 9282231 [details]
python dbus test

Sergo, this is what I put together with SaveFile but I cant get the proper path. Whenever I run this code, I get

f /run/user/1000/gvfs/smb-share:server=nas,share=documents/Patches/Toto/toto.html

While I would expect:

f /run/user/1000/doc/<ID>/Patches/Toto/toto.html

I suspect it could be because of xdp_app_info_is_host https://github.com/flatpak/xdg-desktop-portal/blob/9f03bab1d96a0e87fecd68f24a7045e62e02c0c1/src/file-chooser.c#L118-L121 ?

Are you running this from inside a container? If not, then there is no reason to translate the URIs.

Yes, I'm not running that from inside a container because I dont know how to do so, and I dont know how to manually force the document part to be active when using SaveFile like I do.

Send me the file and the makefile (or what you use to compile it) and I'll send you a snapcraft file to easily create an snap.

(In reply to Sergio Costas from comment #62)

Send me the file and the makefile (or what you use to compile it) and I'll send you a snapcraft file to easily create an snap.

That's not the part I need help about ...

I've managed to package my python as snap, however what I am failing at is:

• somehow it looks like I need some AppArmor profile for DBUs communication ?
• running in devmode I see the file picker but I get no uris in the DBus reply:

$ snap run gio-snap
value (uint32 0, {'choices': <@a(ss) []>, 'uris': <@as []>})
Traceback (most recent call last):

Running the same code and picking the same directory outside of snap gets me:

$ python3 ../gio-snap/test_dbus.py
value (uint32 0, {'choices': <@a(ss) []>, 'uris': <['smb://nas/documents/Patches/Toto/toto.html']>})
f /run/user/1000/gvfs/smb-share:server=nas,share=documents/Patches/Toto/toto.html

Nevermind, this is now because of the way xdg-desktop-portal works, and with your draft fix it works:

$ snap run gio-snap 
value (uint32 0, {'choices': <@a(ss) []>, 'uris': <['file:///run/user/1000/doc/990b964e/toto.html']>})
f /run/user/1000/doc/990b964e/toto.html

Anyway, it seems that the fix must be different. Check https://github.com/flatpak/xdg-desktop-portal/pull/814#discussion_r903852929

It seems that xdg-desktop-portal already have Gvfs support, but seems to be disabled.

(In reply to Sergio Costas from comment #66)

Anyway, it seems that the fix must be different. Check https://github.com/flatpak/xdg-desktop-portal/pull/814#discussion_r903852929

It seems that xdg-desktop-portal already have Gvfs support, but seems to be disabled.

Yes, that was my findings at first and the reason I filed the two upstream issues on bug 1773624

I have confirmation that SaveFiles cannot help us.

Running outside of snap:

$ GTK_USE_PORTAL=1 python3 ../gio-snap/test_dbus.py --save-files
value (uint32 0, {'choices': <@a(ss) []>, 'uris': <['smb://nas/documents/Patches/Toto/tata.html', 'smb://nas/documents/Patches/Toto/caca.dir/pipi.html']>})
f /run/user/1000/gvfs/smb-share:server=nas,share=documents/Patches/Toto/tata.html
writing /run/user/1000/gvfs/smb-share:server=nas,share=documents/Patches/Toto/tata.html
wrote /run/user/1000/gvfs/smb-share:server=nas,share=documents/Patches/Toto/tata.html
creating /run/user/1000/gvfs/smb-share:server=nas,share=documents/Patches/Toto/caca.dir
created /run/user/1000/gvfs/smb-share:server=nas,share=documents/Patches/Toto/caca.dir

Running inside snap:

$ snap run gio-snap --save-files
value (uint32 0, {'choices': <@a(ss) []>, 'uris': <['file:///run/user/1000/doc/afe4cf89/tata.html']>})
f /run/user/1000/doc/afe4cf89/tata.html
writing /run/user/1000/doc/afe4cf89/tata.html
wrote /run/user/1000/doc/afe4cf89/tata.html
creating /run/user/1000/doc/afe4cf89/caca.dir
Traceback (most recent call last):
  File "/snap/gio-snap/x7/bin/test_dbus.py", line 67, in handler_save_files
    new_dir.mkdir()
  File "/usr/lib/python3.8/pathlib.py", line 1288, in mkdir
    self._accessor.mkdir(self, mode)
PermissionError: [Errno 1] Operation not permitted: '/run/user/1000/doc/afe4cf89/caca.dir'
^CTraceback (most recent call last):
  File "/snap/gio-snap/x7/bin/gio-snap-dbus", line 8, in <module>
    sys.exit(main())
  File "/snap/gio-snap/x7/bin/test_dbus.py", line 118, in main
    mainloop.run()
  File "/snap/gio-snap/x7/lib/python3.8/site-packages/gi/overrides/GLib.py", line 497, in run
    super(MainLoop, self).run()
  File "/usr/lib/python3.8/contextlib.py", line 120, in __exit__
    next(self.gen)
  File "/snap/gio-snap/x7/lib/python3.8/site-packages/gi/_ossighelper.py", line 237, in register_sigint_fallback
    signal.default_int_handler(signal.SIGINT, None)
KeyboardInterrupt

Small reproducer calling DBus SaveFile or SaveFiles method. Install with snap install [...] --devmode.

Just a note to say that the old patch for xdg-desktop-portal was closed, and there is a new one here: https://github.com/flatpak/xdg-desktop-portal/pull/822

Filed some upstream issue for the mkdir limitation: https://github.com/flatpak/xdg-desktop-portal/issues/831

BTW: this happens both in the SNAP and the FLATPAK versions of Firefox.

There does not seems to be very much activity upstream, after a very lengthy discussion on https://github.com/flatpak/xdg-desktop-portal/issues/463

Sergio, have you been able to follow this upstream activity? Can we expect something fixed?

That bug is different. That requires a change in the portal protocol to add a new capability, so I suspect that it will require more time... And it would be very useful for other programs, like Kicad (I wanted to pack it, but it requires access to several files in the same folder).

This is the current patch https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/merge_requests/67 It's awaiting review, but as I read some days ago, if I understood it right, the maintainer resigned... https://discourse.gnome.org/t/maintainership-transitions/14478

It looks like upstream still has not reviewed :(