Bug 2134527 - Please set widget.use-xdg-desktop-portal.file-picker=1 by default for Firefox
Summary: Please set widget.use-xdg-desktop-portal.file-picker=1 by default for Firefox
Keywords:
Status: ASSIGNED
Alias: None
Product: Fedora
Classification: Fedora
Component: firefox
Version: 37
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Gecko Maintainer
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedFreezeException
Depends On:
Blocks: F37FinalFreezeException
TreeView+ depends on / blocked
 
Reported: 2022-10-13 14:40 UTC by Neal Gompa
Modified: 2022-12-12 15:26 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Feature Request


Attachments (Terms of Use)

Description Neal Gompa 2022-10-13 14:40:21 UTC
Description of problem:
Firefox on KDE Plasma can only use the correct native file picker if Firefox is configured to always use the xdg-desktop-portal file picker instead of the built-in GTK one. Without using the portal file picker, access to KIO resources and other things simply will not work.

Please patch Firefox to turn this behavior on by default.

(Also, it'd be great to have this for Thunderbird too...)

Version-Release number of selected component (if applicable):
105.0.2-1.fc37

Additional info:
GTK removed the ability to force portals for GTK applications by default, which is the main documented reference for getting Firefox to do the right thing automatically.

Comment 1 Fedora Blocker Bugs Application 2022-10-13 14:41:46 UTC
Proposed as a Freeze Exception for 37-final by Fedora user ngompa using the blocker tracking app because:

 This easy tweak significantly enhances the quality of life for users of Firefox on non-GNOME platforms.

Comment 2 Adam Williamson 2022-10-14 08:36:30 UTC
Have you checked that this actually works, given https://bugzilla.redhat.com/show_bug.cgi?id=2133795 and https://bugs.kde.org/show_bug.cgi?id=458865 upstream where people seem to suggest current xdg-desktop-portal-kde on Qt 5.15.5+ has problems?

Comment 3 Neal Gompa 2022-10-14 09:58:32 UTC
It's working on my machine running Fedora 37, so I was reasonably okay with suggesting this.

Comment 4 Geoffrey Marr 2022-10-17 19:30:18 UTC
Discussed during the 2022-10-17 blocker review meeting: [0]

The decision to classify this bug as an "AcceptedFreezeException (Final)" was made as it would be a substantial improvement for KDE users and affect the live images, but we expect thorough testing before pulling in the change.

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2022-10-17/f37-blocker-review.2022-10-17-16.01.txt

Comment 5 Martin Stransky 2022-10-19 10:44:04 UTC
I expect it needs to be enabled for KDE only. That means we need to detect KDE environment somehow and then set widget.use-xdg-desktop-portal.file-picker (or something else).

Comment 6 Adam Williamson 2022-10-19 14:12:46 UTC
I mean, it ought to work on GNOME too, you'd get a GTK+ portal picker, which should I guess be fine. We could ask the desktop folks for input here...Michael?

Comment 7 Michael Catanzaro 2022-10-19 14:35:08 UTC
All applications should prefer native file choosers because the file chooser won't work at all under Flatpak otherwise. The time for in-process file choosers is long past. Fedora users expect Firefox to have a useful file chooser, so yeah, this request makes sense to me. Plus, even if you're not using Flatpak, it's just nice to have a desktop-native file chooser that supports normal KDE workflows.

That said, it would of course be good to fix this upstream, so that non-Fedora users benefit too.

> GTK removed the ability to force portals for GTK applications by default, which is the main documented reference for getting Firefox to do the right thing automatically.

Background info: users were abusing this to get a nicer file chooser without realizing that a lot of portals do not work for unsandboxed apps. It's actually pretty hard to know what works and what doesn't unless you give each portal a try to see what happens. So you can't just force enable all portals willy-nilly without breaking random things. Many people were doing just that, and it was going to be a real problem (especially for people who deal with bug reports), so that had to go. :/

Comment 8 Martin Stransky 2022-10-20 09:53:54 UTC
Added to firefox-106.0.

Comment 9 Fedora Update System 2022-10-21 07:25:16 UTC
FEDORA-2022-149b2eb8e9 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-149b2eb8e9

Comment 10 Fedora Update System 2022-10-21 07:25:18 UTC
FEDORA-2022-6df8e191d3 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-6df8e191d3

Comment 11 Fedora Update System 2022-10-21 08:24:47 UTC
FEDORA-2022-149b2eb8e9 has been pushed to the Fedora 37 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-149b2eb8e9`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-149b2eb8e9

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 12 Fedora Update System 2022-10-21 09:48:16 UTC
FEDORA-2022-e83147158d has been pushed to the Fedora 36 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-e83147158d`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-e83147158d

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 13 Fedora Update System 2022-10-21 09:52:04 UTC
FEDORA-2022-6df8e191d3 has been pushed to the Fedora 35 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-6df8e191d3`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-6df8e191d3

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 14 nucleo 2022-10-21 13:09:24 UTC
Save as (Ctrl+S) don't work on KDE with firefox-106.0-1.fc37

(firefox:28185): Gtk-WARNING **: 16:03:56.016: Can't open portal file chooser: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name is not activatable

Comment 15 nucleo 2022-10-21 16:16:32 UTC
After installing xdg-desktop-portal Ctrl+S still don't work

(firefox:2679): Gtk-WARNING **: 18:55:11.482: Can't open portal file chooser: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: ????????? ?org.freedesktop.portal.FileChooser? ??? ???? /org/freedesktop/portal/desktop ??????? ?? ??????

Comment 16 Adam Williamson 2022-10-21 16:37:26 UTC
What if you install xdg-desktop-portal-kde ?

Comment 17 Adam Williamson 2022-10-21 16:39:28 UTC
I made sure all updates have a -1 so they don't get autopushed till we investigate nucleo's issue. I would expect it should fall back to the built-in GTK file chooser if it can't use the portal?

Comment 18 nucleo 2022-10-21 17:15:59 UTC
Ctrl+S works after installing xdg-desktop-portal-kde. It was not installed because nothing requires it.

xdg-desktop-portal-kde also installs many dependencies:

flatpak flatpak-selinux flatpak-session-helper geoclue2 low-memory-monitor malcontent-libs ostree-libs xdg-desktop-portal      

Isn't that too much for this file picker feature?

I don't use flatpak, so it also was not installed here.

Comment 19 Adam Williamson 2022-10-21 17:26:03 UTC
It does seem bad if it doesn't just fall back to the built-in file picker if the portal one isn't available. Martin, can you check on that? Thanks!

Comment 20 Vitaly Zaitsev 2022-10-22 11:36:40 UTC
Please revert because if the xdg-desktop-portal package is not installed, user can't save/open files.

Comment 21 Vitaly Zaitsev 2022-10-22 11:53:26 UTC
Also please don't add a strict dependency on xdg-desktop-portal, because it depends on flatpak (don't know why).

I suggest the following:
Recommends: xdg-desktop-portal%{?_isa}
Recommends: (xdg-desktop-portal-gnome%{?_isa} if gnome-shell%{?_isa})
Recommends: (xdg-desktop-portal-kde%{?_isa} if plasma-workspace-wayland%{?_isa})
Recommends: (xdg-desktop-portal-wlr%{?_isa} if wlroots%{?_isa})

I already use this in the telegram-desktop package. Works well for most users.

Comment 22 Michael Catanzaro 2022-10-22 15:06:57 UTC
It might work, but should every application need to cargo cult this hardcoded list of portals to Recommends? Keeping them all in sync will become a mess. Firefox shouldn't need to worry about this. Reverse dependencies are much cleaner here, and they already exist. xdg-desktop-portal-gnome already has Supplements: gnome-shell, and xdg-desktop-portal-gtk already has Supplements: gtk3. And Firefox depends on gtk3, so every Firefox user should have xdg-desktop-portal-gtk installed UNLESS (a) they have disabled weak deps, opting into some breakage to keep installed dependencies minimal, or (b) there exists a bug in dnf or PackageKit causing the Supplements to be improperly missed. Right? Then xdg-desktop-portal-gtk Requires: xdg-desktop-portal. So everything should be fine: I think it should only break for users who manually uninstall the portals. Am I wrong?

xdg-desktop-portal-kde currently has Supplements: (plasma-desktop and (flatpak or snapd)). It should be just Supplements: plasma-desktop, since plenty of desktop applications require portals nowadays. That would ensure it gets installed for every KDE user.

Lastly, xdg-desktop-portal-wlr has:

Enhances:       sway
Supplements:    (sway and (flatpak or snapd))

I would replace all that with Supplements: wlroots.

(P.S. xdg-desktop-portal Recommends: flatpak because that provides the icon validator, which I think is required for the notification portal?)

Comment 23 Vitaly Zaitsev 2022-10-22 15:42:59 UTC
> (P.S. xdg-desktop-portal Recommends: flatpak because that provides the icon validator, which I think is required for the notification portal?)

xdg-desktop-portal-kde has a strict dependency on flatpak: https://src.fedoraproject.org/rpms/xdg-desktop-portal-kde/blob/rawhide/f/xdg-desktop-portal-kde.spec#_48

> It might work, but should every application need to cargo cult this hardcoded list of portals to Recommends? Keeping them all in sync will become a mess.

True.

Comment 24 Adam Williamson 2022-10-22 15:47:29 UTC
It still seems pretty bad to me that file save / open would not work if you have weak dependencies disabled. That's a subjective line, of course, but me that's where I draw it.

Why *can't* Firefox fall back if the portal isn't available? I've seen some references to setting this setting to =2, not =1, but couldn't figure out what that does; does anyone know?

Comment 25 Vitaly Zaitsev 2022-10-22 15:54:12 UTC
> Why *can't* Firefox fall back if the portal isn't available?

Value 1 enforces portals.

> I've seen some references to setting this setting to =2, not =1, but couldn't figure out what that does; does anyone know?

0 - always use built-in GTK dialogs.
1 - always use portals.
2 (default value) - use portals only if GTK_USE_PORTAL=1 environment option is set.

Comment 26 Vitaly Zaitsev 2022-10-22 16:04:58 UTC
> xdg-desktop-portal-kde currently has Supplements: (plasma-desktop and (flatpak or snapd)). It should be just Supplements: plasma-desktop, since plenty of desktop applications require portals nowadays. That would ensure it gets installed for every KDE user.

Done: https://src.fedoraproject.org/rpms/xdg-desktop-portal-kde/pull-request/1

Comment 27 Adam Williamson 2022-10-22 16:15:04 UTC
But there's no "try and use portals, fall back on built-in GTK dialog if it doesn't work" setting? well, that sucks.

Comment 28 Neal Gompa 2022-10-22 16:26:19 UTC
(In reply to Michael Catanzaro from comment #22)
> (P.S. xdg-desktop-portal Recommends: flatpak because that provides the icon
> validator, which I think is required for the notification portal?)

That was the case, yes. But it looks like xdg-desktop-portal now vendors a copy of the validator and uses that when the flatpak one isn't present. The flatpak dependency can and should be dropped across *all* portal implementations now, and removed from the portal runtime dependency chain entirely.

Comment 29 Martin Stransky 2022-10-25 09:25:27 UTC
Revered in firefox-106.0.1 due to issues here.

Comment 30 Martin Stransky 2022-10-26 08:14:35 UTC
(In reply to Adam Williamson from comment #27)
> But there's no "try and use portals, fall back on built-in GTK dialog if it
> doesn't work" setting? well, that sucks.

I'd expect this functionality from Gtk3 code. We use Gtk3 file picker - why an application needs to care which file dialog is used?
If Gtk3 implements that (portals/local filepicker according to system setup), all Gtk3 apps will use that.
Do we really want Firefox specific hacks here? Do we want to fix/hack all Gtk3 apps?

Comment 31 Martin Stransky 2022-10-26 08:21:19 UTC
Related Firefox code is here:
https://searchfox.org/mozilla-central/rev/59f0bf3c13dd455d9f5415b89178de701ea6b850/widget/gtk/nsFilePicker.cpp#609

So when portals are enforced (widget.use-xdg-desktop-portal.file-picker=1) it looks like:

set env GTK_USE_PORTAL=1
gtk_native_dialog_show()
unset env GTK_USE_PORTAL

So the GTK_USE_PORTAL env variable is only way (AFAIK) how to enable/disable portals in gtk_native_dialog_show().
Firefox may check error code from gtk_native_dialog_show() and try to clear GTK_USE_PORTAL if that fails (and we're not in Flatpak).

Anyway, patches welcome as usual :)

Comment 32 Michael Catanzaro 2022-10-26 14:18:55 UTC
(In reply to Martin Stransky from comment #30)
> set env GTK_USE_PORTAL=1
> gtk_native_dialog_show()
> unset env GTK_USE_PORTAL

The GTK_USE_PORTAL environment variable was removed from GTK, so that does not do anything except risk crashing Firefox. I warn about this in https://blogs.gnome.org/mcatanzaro/2018/02/28/on-setenv-and-explosions/. I recommend removing that and auditing the rest of Firefox for similar unsafe use of setenv()/unsetenv(). In particular, note the section "This is not some theoretical problem. In practice, we have documented..." for scary past anecdotes.

> I'd expect this functionality from Gtk3 code. We use Gtk3 file picker - why
> an application needs to care which file dialog is used?
> If Gtk3 implements that (portals/local filepicker according to system
> setup), all Gtk3 apps will use that.
> Do we really want Firefox specific hacks here? Do we want to fix/hack all
> Gtk3 apps?

Firefox's job is to use GtkFileChooserNative instead of the normal GtkFileChooser. I didn't realize that the native file chooser was sometimes displayed in-process instead of always going through the portal. I agree that should be changed in GTK, not in Firefox.

Comment 33 Michael Catanzaro 2022-10-26 14:30:15 UTC
(In reply to Michael Catanzaro from comment #32)
> The GTK_USE_PORTAL environment variable was removed from GTK, so that does
> not do anything except risk crashing Firefox.

Whoops, I see that's true in GTK 4, but not true of GTK 3.

Regardless, still shouldn't do it.

Comment 34 Michael Catanzaro 2022-10-26 14:35:14 UTC
Upstream bug report: https://gitlab.gnome.org/GNOME/gtk/-/issues/5026

Comment 35 Martin Stransky 2022-11-01 08:27:44 UTC
Thanks. What should be done on Firefox side? Remove GTK_USE_PORTAL, okay, and then?

Comment 36 Michael Catanzaro 2022-11-01 13:48:25 UTC
(In reply to Martin Stransky from comment #35)
> Thanks. What should be done on Firefox side? Remove GTK_USE_PORTAL, okay,
> and then?

I'd say that's all for this issue. Firefox's job is to use GtkFileChooserNative. That's how you opt-in to use of the file chooser portal. The fact that GTK doesn't actually use the portal is a GTK problem.

However, you could use the portal D-Bus APIs directly if you really want to force use of the portal.

Comment 37 Michael Catanzaro 2022-11-18 15:10:01 UTC
OK, upstream update on this:

https://gitlab.gnome.org/GNOME/gtk/-/issues/5026
https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/5221

To get the portal always, you must switch from GtkFileChooserNative to GtkFileDialog. This will require GTK 4.10 or newer.

Comment 38 Martin Stransky 2022-11-18 19:32:30 UTC
(In reply to Michael Catanzaro from comment #37)
> OK, upstream update on this:
> 
> https://gitlab.gnome.org/GNOME/gtk/-/issues/5026
> https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/5221
> 
> To get the portal always, you must switch from GtkFileChooserNative to
> GtkFileDialog. This will require GTK 4.10 or newer.

Firefox is far away from switch to Gtk4.


Note You need to log in before you can comment on or make changes to this bug.