[Bug]: Obscure error message at start-up

[WhyNotHugo]

Describe the bug

Upon opening Tuba I get the following error message:

(apologies for sending a screenshot; copying this text is disabled for some reason, but I guess that's a separate issue)

Steps To Reproduce

1. Open Tuba

Logs and/or Screenshots

(tuba:9570): Tuba-CRITICAL **: 15:12:16.059: SecretAccountStore.vala:46: Error while searching for items in the secret service: The name org.freedesktop.secrets was not provided by any .service files

(tuba:9570): Tuba-WARNING **: 15:12:16.059: SecretAccountStore.vala:47: If you didn’t manually cancel it, try creating a password keyring named "login" using Passwords and Keys (seahorse) or KWalletManager
read more: https://github.com/GeopJr/Tuba/wiki/keyring-issues

Instance Backend

Mastodon

Operating System

Alpine Linux Edge

Package

OS repositories

Troubleshooting information

I can't access this menu.

Additional Context

The main issue here is the obscurity of the error message:

If you didn't manually cancel **it**, …

I've no idea what "it" is referring to here.

Clicking on the "Read More" button immediately exits. The following additional line is logged:

(tuba:9570): Gtk-WARNING **: 15:13:19.301: Not a supported version of the OpenURI portal: 0

[WhyNotHugo]

In my secret-service backend (KeePassXC) I see an entry named "Mastodon Account". So it looks like credentials are still there.

[GeopJr]

Okay, there's clearly issues with the portals.

Clicking on the "Read More" button immediately exits. The following additional line is logged:

It's supposed to exit but also open a wiki page in your browser, did it open?

Not a supported version of the OpenURI portal: 0

This plus the keyring error makes me believe that you are either missing desktop portals or something's wrong with them(?)

What's the output of ls /usr/share/xdg-desktop-portal/portals/?

cc: @stacyharper if you have any idea or insights

I've no idea what "it" is referring to here.

Needs better wording, but there's not (or wasn't? haven't checked in a while) a way to reliably differentiate between a portal issue and the user clicking cancel when their desktop asks them to unlock their keyring. 'It' refers to the keyring unlock dialog.

[stacyharper]

mhh best clue would be that KeePassXC stopped responding as a org.freedesktop.secrets provider?

fwiw everything seems to still works here (but I don't use KeePassXC).

I might also suffer the OpenURI issue. Because no portal implementation that I have installed support this. But this is not specific to Tuba.

[GeopJr]

I might also suffer the OpenURI issue. Because no portal implementation that I have installed support this. But this is not specific to Tuba.

I can switch back to the dbus one (which is currently the fallback for when the portal one fails, that's why I want to see if the wiki page ended up opening or not). Though from what I can tell libadwaita widgets that need to open uris also use the portal one (e.g. links in about dialog)

[WhyNotHugo]

What's the output of ls /usr/share/xdg-desktop-portal/portals/?

> ls /usr/share/xdg-desktop-portal/portals
darkman.portal     way-access.portal  wlr.portal

Tuba is running via a native package; the desktop portal should not be required for anything in this case, right? See below.

It is running in my situation, but I haven't configured all of its backends, since I don't really need them for anything else.

It's supposed to exit but also open a wiki page in your browser, did it open?

It did not.

mhh best clue would be that KeePassXC stopped responding as a org.freedesktop.secrets provider?

Yeah, looks like it has stopped doing so. It's not the first time that KPXC stops responding to these. I'll keep this in mind next time that I see related issues.

I might also suffer the OpenURI issue. Because no portal implementation that I have installed support this. But this is not specific to Tuba.

I think that using xdg-open would be the portable approach here. Flatpak replaces this executable with a binary that calls OpenURI under the hood. I expect that other sandbox engines do the same (it's definitely what I do when I manually sandbox processes).

Shall I create a separate issue for this?

[GeopJr]

Glad it got figured out!

Shall I create a separate issue for this?

I'd say probably not. It's on GTK's side to figure out when it should be using the portal or not. No idea why it wants to use the portal for your case. Spawning xdg-open when there not one but two APIs for opening uris feels excessive...

Links open using Gtk.UriLauncher, which uses the portal if it's available.
GTK detects if it should use the portal here: https://gitlab.gnome.org/GNOME/gtk/-/blob/main/gdk/gdk.c#L416-426
You can pass GDK_DEBUG=no-portals to prevent GTK from using the portals as a workaround.

(My guess on why it didn't open is that when switching to UriLauncher which is async, I forgot to await it before exiting for this case, oops)

[stacyharper]

I think that using xdg-open would be the portable approach here. Flatpak replaces this executable with a binary that calls OpenURI under the hood. I expect that other sandbox engines do the same (it's definitely what I do when I manually sandbox processes).

I would love if someone could write a tiny soft that respond to this portal and trigger our dear xdg-open :3

[GeopJr]

I gave it a try though, THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS “AS IS” AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. (don't want to be responsible for any security holes)

https://github.com/geopjr-forks/xdg-desktop-portal-faraway

I avoided using xdg-open since it can call the portal. Instead, if there's a content type provided, it spawns xdg mime and if the result is between the available choices it uses it. Else it checks if the 'last_used' is available and finally picks the first available choice.

[WhyNotHugo]

Honestly, running another daemon so that Tuba con open links using the default app seems too many layers of indirection; just calling xdg-open should suffice.

I'm using Alpine, so xdg-desktop-portal-faraway won't work due to requiring a different init implementation.

[WhyNotHugo]

(My guess on why it didn't open is that when switching to UriLauncher which is async, I forgot to await it before exiting for this case, oops)

If this is the case and you manage to patch this, I can test that patch :)

[GeopJr]

Honestly, running another daemon so that Tuba con open links using the default app seems too many layers of indirection; just calling xdg-open should suffice.

It's not just Tuba though, the main issue is GTK's for whatever reason deciding to use the portal when none of the available portals handle AppChooser. What I'm trying to get at is that every GTK app that uses the high level APIs provided by GTK to open links will also fail.

I'm using Alpine, so xdg-desktop-portal-faraway won't work due to requiring a different init implementation.

that's from elementary (which this portal is based on), from what I can tell it's only used for when systemduserunitdir (meson option) is not provided - which is used for the install location of org.freedesktop.impl.portal.desktop.faraway.service

The whole portal is really small, it wouldn't take much to configure it to your needs

If this is the case and you manage to patch this, I can test that patch :)

give me a second!

---

edit: xdg-desktop-portal-faraway now doesn't require systemd, took the default path from the gtk portal

[GeopJr]

#1291 worked as expected from my testing

Actually I might be wrong above and GTK might do the right thing but I confused the fact that the link didn't open due to async to GTK not opening them

edit: either way I wrote that portal because Willow brought it up