Bug 2134527

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.

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?

It's working on my machine running Fedora 37, so I was reasonably okay with suggesting this.

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

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).

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?

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. :/

Added to firefox-106.0.

FEDORA-2022-149b2eb8e9 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-149b2eb8e9

FEDORA-2022-6df8e191d3 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-6df8e191d3

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.

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.

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.

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

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 ??????? ?? ??????

What if you install xdg-desktop-portal-kde ?

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?

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.

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!

Please revert because if the xdg-desktop-portal package is not installed, user can't save/open files.

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.

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?)

> (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.

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?

> 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.

> 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

But there's no "try and use portals, fall back on built-in GTK dialog if it doesn't work" setting? well, that sucks.

(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.

Revered in firefox-106.0.1 due to issues here.

(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?

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 :)

(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.

(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.

Upstream bug report: https://gitlab.gnome.org/GNOME/gtk/-/issues/5026

Thanks. What should be done on Firefox side? Remove GTK_USE_PORTAL, okay, and then?

(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.

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.

(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.

Interestingly enough, I had no idea users could turn this on as a setting in Firefox, until I read https://bugzilla.mozilla.org/show_bug.cgi?id=1658011#c10 ... so now that I turned on the setting, I get the GTK 4.10 FileChooser with Firefox instead of the GTK3 one, unlike what upstream supposed. It "just worked" for me, but of course I presumably have all dependencies satisfied as I am running GNOME on F38...

This message is a reminder that Fedora Linux 37 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 37 on 2023-12-05.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '37'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 37 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Fedora Linux 37 entered end-of-life (EOL) status on None.

Fedora Linux 37 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

Thank you for reporting this bug and we are sorry it could not be fixed.

This is still a problem today.

This bug appears to have been reported against 'rawhide' during the Fedora Linux 40 development cycle.
Changing version to 40.