Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The portal config file does not actually specify the order of portals to be tried #1111

Open
q234rty opened this issue Sep 23, 2023 · 4 comments · May be fixed by #1240
Open

The portal config file does not actually specify the order of portals to be tried #1111

q234rty opened this issue Sep 23, 2023 · 4 comments · May be fixed by #1240
Labels
bug config Issues with the portal configuration mechanism needs discussion Needs discussion on how to implement or fix the corresponding task

Comments

@q234rty
Copy link

q234rty commented Sep 23, 2023

The documentation suggests that

Each key in the group contains a semi-colon separated list of portal backend
implementation, to be searched for an implementation of the requested interface,
in the same order as specified in the configuration file.

However, this does not seems to match the actual behavior: In KDE with

[preferred]
org.freedesktop.impl.portal.FileChooser=gtk;kde

The kde file chooser is still opened despite gtk being specified first.

Looking at the code, it seems that the implementation are sorted based on UseIn and name in https://github.com/flatpak/xdg-desktop-portal/blob/1.18.0/src/portal-impl.c#L317 , then tried in that order in https://github.com/flatpak/xdg-desktop-portal/blob/1.18.0/src/portal-impl.c#L550 , so instead of searching in the same order as in the config and returning the first portal implementing the interface, which is what the documentation suggests, it searches in the "old" order based on UseIn and name, using the config only as an allowed list of portals.

@q234rty q234rty changed the title The portal config file can not actually specify the order of portals to be tried The portal config file does not actually specify the order of portals to be tried Sep 24, 2023
@GeorgesStavracas
Copy link
Member

@ebassi I wonder if something like this would be enough to follow the order specific in the config file:

diff --git a/src/portal-impl.c b/src/portal-impl.c
index 0fa9682..d363ddc 100644
--- a/src/portal-impl.c
+++ b/src/portal-impl.c
@@ -608,21 +608,34 @@ GPtrArray *
 find_all_portal_implementations (const char *interface)
 {
+  g_autoptr(GHashTable) impls_map = NULL;
   GPtrArray *impls;
-  GList *l;
 
   impls = g_ptr_array_new ();
 
-  for (l = implementations; l != NULL; l = l->next)
+  if (config == NULL)
+    {
+      g_critical ("What do we do in this case?");
+      return impls;
+    }
+
+  impls_map = g_hash_table_new (g_str_hash, g_str_equal);
+  for (GList *l = implementations; l != NULL; l = l->next)
     {
       PortalImplementation *impl = l->data;
+      g_hash_table_insert (impls_map, impl->source, impl);
+    }
 
-      if (!g_strv_contains ((const char **)impl->interfaces, interface))
+  for (size_t i = 0; i < config->n_ifaces; i++)
+    {
+      PortalInterface *portal_interface = config->interfaces[i];
+
+      if (g_strcmp0 (portal_interface->dbus_name, interface) != 0)
         continue;
 
-      if (portal_impl_matches_config (impl, interface))
+      for (size_t j = 0; portal_interface->portals[j] != NULL; j++)
         {
+          PortalImplementation *impl;
+
+          impl = g_hash_table_lookup (impls_map, portal_interface->portals[j]);
+
+          if (impl == NULL)
+            continue;
+
+          if (!g_strv_contains ((const char **)impl->interfaces, interface))
+            continue;
+
           g_debug ("Using %s.portal for %s (config)", impl->source, interface);
           g_ptr_array_add (impls, impl);
         }

@GeorgesStavracas
Copy link
Member

hm, no, probably not

@GeorgesStavracas GeorgesStavracas added bug config Issues with the portal configuration mechanism needs discussion Needs discussion on how to implement or fix the corresponding task labels Oct 3, 2023
alyssais added a commit to alyssais/xdg-desktop-portal that referenced this issue Dec 12, 2023
Quoting portals.conf(5):

> Each key in the group contains a semi-colon separated list of portal backend
> implementation, to be searched for an implementation of the requested interface,
> in the same order as specified in the configuration file.

But this wasn't actually true.  If the portals were set to z;y and z
and y both implemented the same portal, y would be used.

Fixing this requires reworking how portals are selected — going
through the config file and selecting the first available configured
portal, rather than going through each known portal and checking
whether it's allowed in the config file.

find_all_portal_implementations() is unchanged.  The portal-first
approach is fine for it, and it would be difficult for it to share as
much code with find_portal_implementation() now that it's written to
stop as soon as a configured portal is found.

Fixes: flatpak#1111
@alyssais alyssais linked a pull request Dec 12, 2023 that will close this issue
@alyssais
Copy link
Contributor

I've opened #1240 to try to fix this.

@GeorgesStavracas
Copy link
Member

Thanks, very much appreciated

alyssais added a commit to alyssais/xdg-desktop-portal that referenced this issue Dec 27, 2023
Quoting portals.conf(5):

> Each key in the group contains a semi-colon separated list of portal backend
> implementation, to be searched for an implementation of the requested interface,
> in the same order as specified in the configuration file.

But this wasn't actually true.  If the portals were set to z;y and z
and y both implemented the same portal, y would be used.

Fixing this requires reworking how portals are selected — going
through the config file and selecting the first available configured
portal, rather than going through each known portal and checking
whether it's allowed in the config file.

find_all_portal_implementations() is unchanged.  The portal-first
approach is fine for it, and it would be difficult for it to share as
much code with find_portal_implementation() now that it's written to
stop as soon as a configured portal is found.

Fixes: flatpak#1111
alyssais added a commit to alyssais/xdg-desktop-portal that referenced this issue Dec 29, 2023
Quoting portals.conf(5):

> Each key in the group contains a semi-colon separated list of portal backend
> implementation, to be searched for an implementation of the requested interface,
> in the same order as specified in the configuration file.

But this wasn't actually true.  If the portals were set to z;y and z
and y both implemented the same portal, y would be used.

Fixing this requires reworking how portals are selected — going
through the config file and selecting the first available configured
portal, rather than going through each known portal and checking
whether it's allowed in the config file.

find_all_portal_implementations() is unchanged.  The portal-first
approach is fine for it, and it would be difficult for it to share as
much code with find_portal_implementation() now that it's written to
stop as soon as a configured portal is found.

Fixes: flatpak#1111
alyssais added a commit to alyssais/xdg-desktop-portal that referenced this issue Dec 30, 2023
Quoting portals.conf(5):

> Each key in the group contains a semi-colon separated list of portal backend
> implementation, to be searched for an implementation of the requested interface,
> in the same order as specified in the configuration file.

But this wasn't actually true.  If the portals were set to z;y and z
and y both implemented the same portal, y would be used.

Fixing this requires reworking how portals are selected — going
through the config file and selecting the first available configured
portal, rather than going through each known portal and checking
whether it's allowed in the config file.

find_all_portal_implementations() is unchanged.  The portal-first
approach is fine for it, and it would be difficult for it to share as
much code with find_portal_implementation() now that it's written to
stop as soon as a configured portal is found.

Fixes: flatpak#1111
alyssais added a commit to alyssais/xdg-desktop-portal that referenced this issue Jan 2, 2024
Quoting portals.conf(5):

> Each key in the group contains a semi-colon separated list of portal backend
> implementation, to be searched for an implementation of the requested interface,
> in the same order as specified in the configuration file.

But this wasn't actually true.  If the portals were set to z;y and z
and y both implemented the same portal, y would be used.

Fixing this requires reworking how portals are selected — going
through the config file and selecting the first available configured
portal, rather than going through each known portal and checking
whether it's allowed in the config file.

find_all_portal_implementations() is unchanged.  The portal-first
approach is fine for it, and it would be difficult for it to share as
much code with find_portal_implementation() now that it's written to
stop as soon as a configured portal is found.

Fixes: flatpak#1111
SoumyaRanjanPatnaik added a commit to regolith-linux/xdg-desktop-portal-regolith that referenced this issue Apr 3, 2024
…o gnome) to regolith portal

Portals may not follow the expected ordering as per [this](flatpak/xdg-desktop-portal#1111) issue.

This causes some of the interfaces that are made available by other backend (like gtk or wlr) to get assigned to the no-op
implementations of the xdp-regolith backend.

This PR explicitly assigns only the problematic interfaces, i.e. the ones that get assigned to xdp-gnome, to the regolith backend.
SoumyaRanjanPatnaik added a commit to regolith-linux/xdg-desktop-portal-regolith that referenced this issue Apr 3, 2024
…o gnome) to regolith portal

Portals may not follow the expected ordering as per [this](flatpak/xdg-desktop-portal#1111) issue.

This causes some of the interfaces that are made available by other backend (like gtk or wlr) to get assigned to the no-op
implementations of the xdp-regolith backend.

This PR explicitly assigns only the problematic interfaces, i.e. the ones that get assigned to xdp-gnome, to the regolith backend.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug config Issues with the portal configuration mechanism needs discussion Needs discussion on how to implement or fix the corresponding task
Projects
Status: Triaged
Development

Successfully merging a pull request may close this issue.

3 participants