[flatpak] Use file chooser portal
Categories
(Core :: Widget: Gtk, enhancement)
Tracking
()
People
(Reporter: mail, Unassigned)
Details
Attachments
(1 file, 1 obsolete file)
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:80.0) Gecko/20100101 Firefox/80.0
Steps to reproduce:
Try to open a file by a web application (e.g. uploading something to Google drive).
Actual results:
The file chooser only let me see files stored in Downloads.
(There's a separate bug I have here where firefox is confined to only Downloads and if I give it access to my full home folder it won't find my profile during restart)
Expected results:
Ideally Firefox should not have access to any folders, but open/store files through xdg-desktop-portal.
Hi, Kai!
Thanks for your contribution!
I'll add product and component since this has been marked as enhancement.
Regards,
This might be a duplicate of Bug 1675312
Can firefox switch to using GtkFileChooserNative by default? After doing this firefox will use DE file picker, which is great.
Related:
https://github.com/electron/electron/issues/2911#issuecomment-428686101
https://github.com/electron/electron/pull/19159
The linked bug says to set "widget.use-xdg-desktop-portal" to true. This does indeed enable XDG file chooser!
Is there a reason not to enable this by default, or at least when on flatpak?
|
||
Comment 6•4 years ago
|
||
widget.use-xdg-desktop-portal should be set to true for the flatpak release.
Additionally, the Flatpak manifest should no longer require access to ~/downloads, since the portal should be used instead.
|
|
||
Comment 7•4 years ago
|
||
Related to #1278719
|
||
Comment 8•2 years ago
|
||
Am I right in presuming that using this for all cases (even outside of flatpaks/snaps) would give the browser access to the latest GTK FileChooser (among others) even if Firefox's core widgetry itself is not ported to GTK4 yet (bug #1701123), so that Firefox could benefit from the fact that GTK 4.10's FileChooser finally provides a grid view with thumbnails?
|
|
||
Comment 9•2 years ago
|
||
@Jeff:
xdg-desktop-portal-gtk still uses GTK3 and, as far as I understand, there's an unwillingness to port to GTK4 since the authors want recent versions of the portal to run on older releases of distributions that didn't ship GTK4.
So no, this won't make Firefox use the new FileChooser unless you're using GNOME. GNOME does uses it own xdg-desktop-portal with a separate FileChooser portal implementation.
|
||
Comment 10•2 years ago
|
||
We use the file picker portal right now in Flatpak already, as per this code. Users can enable the portal by pref, but switching it on by default should be a different bug.
|
||
Comment 11•1 month ago
•
|
||
| resolved | ||
switching it on by default should be a different bug.
Does one exist? I ask because:
-
This is tracked downstream, at
bugzilla.redhat.com/show_bug.cgi?id=2134527, and we should discourage patches. -
widget.use-xdg-desktop-portal.file-pickeralways forces theGtkFileChooser:Name : firefox Version : 147.0.2 Release : 1.fc43 Architecture: x86_64 Install Date: Tue 03 Feb 2026 23:40:04 GMT Size : 271019047 Signature : RSA/SHA256, Mon 02 Feb 2026 07:55:15 GMT, Key ID 829b606631645531 Source RPM : firefox-147.0.2-1.fc43.src.rpm Build Date : Fri 30 Jan 2026 10:19:40 GMT Build Host : buildhw-x86-02.rdu3.fedoraproject.org Packager : Fedora Project Vendor : Fedora ProjectI've tried values of
0to3.
|
||
Comment 12•1 month ago
|
||
(In reply to Mr. Beedell, Roke Julian Lockhart (RJLB) from comment #11)
Created attachment 9542369 [details]
A Screencast That Demonstrates That It Cannot Be Enabled Any Moreswitching it on by default should be a different bug.
Does one exist? I ask because:
I'm not really a good person to needinfo here. I don't know our Linux file picking code and it doesn't come under Firefox :: File Handling (which is more about downloads and how we deal with that), but under Core :: Widget: GTK (so I'll move it). The bit you quoted ("switching it on by default should be a different bug.") was also not me. I have never seen this bug before in my life. I struggle to follow your screencast - AFAICT it does not seem to illustrate what you expect to happen, and what you are wanting to switch "on" or "off" or any of that. It just apparently shows that updating the pref does not change behaviour.
Some casual bugzilla searching finds bug 1981100 which was a change in 143, and linked is bug 1991731 which hints that depending on how your file picker works things may or may not be broken (because the external-to-Firefox file picker implementation is... not always correct).
In any case, I would suggest that if you've found something else that's broken (like the pref not doing anything despite it being listed as doing something), you file a new bug for that specific symptom and (ideally) run mozregression to find out when it broke.
Commenting on old closed bugs usually doesn't work. Bugs are cheap, unless you're confident (and have the relevant bugzilla privileges) to reopen a bug directly, file a new one rather than commenting.
- This is tracked downstream, at
bugzilla.redhat.com/show_bug.cgi?id=2134527, and we should discourage patches.
I don't understand what "we should discourage patches" is meant to mean here. I think when things are broken... patches are good? Normally? 🤷
|
|
||
Comment 13•1 month ago
|
||
I'm not really a good person to needinfo here. I don't know our Linux file picking code and it doesn't come under Firefox :: File Handling (which is more about downloads and how we deal with that), but under Core :: Widget: GTK (so I'll move it). The bit you quoted ("switching it on by default should be a different bug.") was also not me. I have never seen this bug before in my life.
My apologies. I selected the triage owner, which I'd presumed had been the one to originally triage this.
I struggle to follow your screencast - AFAICT it does not seem to illustrate what you expect to happen, and what you are wanting to switch "on" or "off" or any of that. It just apparently shows that updating the pref does not change behaviour.
In retrospect, this is remediated in firefox-nightly-149.0a1-20260204094524, which I've demonstrated in an attached screencast: 0 utilises the GtkFileChooser, but 2 is the default, and invokes the QFileDialog.
I don't understand what "we should discourage patches" is meant to mean here.
I meant that having downstream patch their builds, rather than submitting changes upstream, probably isn't ideal, because it causes distribution builds to diverge.
Commenting on old closed bugs usually doesn't work. Bugs are cheap, unless you're confident (and have the relevant bugzilla privileges) to reopen a bug directly, file a new one rather than commenting.
Due to id=1864191, I can't ask mere questions, so I'm confined to BZ, and filing a ticket for a question isn't correct. However, luckily, the attached screencast also demonstrates that this has become the default in firefox-nightly-149.0a1-20260204094524, too!
|
|
||
Comment 14•1 month ago
|
||
I sent a patch in bug 1949057 to let it ride the trains to release.
Description
•