-
-
Notifications
You must be signed in to change notification settings - Fork 182
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
Labels
bug
config
Issues with the portal configuration mechanism
needs discussion
Needs discussion on how to implement or fix the corresponding task
Comments
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
@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);
} |
hm, no, probably not |
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
I've opened #1240 to try to fix this. |
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
The documentation suggests that
However, this does not seems to match the actual behavior: In KDE with
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.
The text was updated successfully, but these errors were encountered: