Cannot create/ install dynamic launchers #1674

eyekay-gh · 2025-03-19T14:35:38Z

Operating System

Debian sid

XDG Desktop Portal version

Other

XDG Desktop Portal version (Other)

1.20.0

Desktop Environment

GNOME

Desktop Environment (Other)

No response

Expected Behavior

The dynamic launcher should be installed successfully.

Current Behavior

I get an error that the desktop entry given to install() is not valid.

g-io-error-quark: GDBus.Error:org.freedesktop.portal.Error.InvalidArgument: Desktop entry given to Install() not valid (36)

Steps to Reproduce

Install Web Apps and create a new web app
Click 'Install' in the dialog
The web app isn't installed, the call to portal.dynamic_launcher_install() fails with this error in the terminal:
g-io-error-quark: GDBus.Error:org.freedesktop.portal.Error.InvalidArgument: Desktop entry given to Install() not valid (36)

Anything else we should know?

This is the code I am running (python):
desktop_file = '[Desktop Entry]\nType=Application\nExec=webapps {}\nTerminal=false\nCategories=Network;'.format(app_id)

...

portal.dynamic_launcher_install(token, "net.codelogistics.webapps." + app_id + ".desktop", desktop_file)

where app_id is in the format "webapp-{UUID}".

This was working fine till a few months ago in both GNOME and KDE. I don't know whether this is a bug in xdg-desktop-portal or libportal, or in my app.

The text was updated successfully, but these errors were encountered:

swick · 2025-03-21T11:28:59Z

I assume the app which tries to use the dynamic launcher portal is a flatpak? We recently tightened the app id requirements to follow what flatpak considers a valid app id: https://github.com/flatpak/xdg-desktop-portal/blob/119aad03548f85ed249b7f21cd551f77bc74e4dd/src/xdp-app-info-flatpak.c#L173C1-L173C41 In other words, if your app is a flatpak, it should not be able to create sub-app-id's which are not valid flatpak app ids.

eyekay-gh · 2025-03-21T14:15:04Z

Thanks, my app was using hyphens instead of underscores in the app IDs, I have fixed it now.

Unfortunately, I still get the same error (g-io-error-quark: GDBus.Error:org.freedesktop.portal.Error.InvalidArgument: Desktop entry given to Install() not valid (36)) when I call dynamic_launcher_install. I believe the app ids generated now are valid (net.codelogistics.webapps.webapp_UUID with underscored in the UUID).

swick · 2025-03-21T16:43:03Z

You might run into the 255 bytes limit.

eyekay-gh · 2025-03-25T08:54:34Z

Thanks, but that is not the case, the total length of the desktop file's name is under 255 chars.

I cannot install web apps using GNOME Web (installed via Flatpak) either. (The text of the notification gets cut off in the notification panel, so I cannot attach the full error message.)

mcatanzaro · 2025-03-25T13:29:12Z

Moving from https://gitlab.gnome.org/GNOME/epiphany/-/issues/2616, I'll note that the same version of xdg-desktop-portal works perfectly fine for me. Clearly the call to g_desktop_app_info_new_from_keyfile() is failing, which is unusual.

GDesktopAppInfo hasn't changed recently. GKeyfile had some changes to locale handling here, but I doubt it's related.

I think next step here is to add a call to g_key_file_to_data() right before the g_desktop_app_info_new_from_keyfile() and print the result. Or alternatively: step into g_desktop_app_info_new_from_keyfile() with gdb and see where precisely it is failing. Since you're a software developer, want to try one or both?

swick · 2025-03-25T14:36:47Z

What I noticed is that g_desktop_app_info_new_from_keyfile requires the Exec part to be an existing executable. I.e. in test_dynamiclauncher.py, if you change Exec in DESKTOP_FILE from true to doesnotexist, the test fails with the same error message.

mcatanzaro · 2025-03-25T17:21:52Z

OK, but epiphany and webapps already exist if the user is using them to install web apps.

swick · 2025-03-25T17:32:35Z

Well, the desktop file provided in the comment is:

[Desktop Entry]
Type=Application
Exec=webapps some.app.id
Terminal=false
Categories=Network;

and it fails.

[Desktop Entry]
Type=Application
Exec=true some.app.id
Terminal=false
Categories=Network;

This works.

So my guess is that somehow the systems of the people affected do not have the programs in their path for some reason.

hfiguiere · 2025-03-25T17:36:55Z

If this is meant to launch a flatpak then it's obviously wrong.

When flatpak exports a .desktop as installed in the package, it does rewrite the Exec line to run flatpak run as appropriate. So a flatpak app install .desktop file should do the same.

swick · 2025-03-25T17:47:32Z

Blergh, I had another look. We first pass the provided data to g_desktop_app_info_new_from_keyfile and then rewrite the Exec lines, so this obviously doesn't work because webapps isn't in path, only flatpak run ... is.

The g_desktop_app_info_new_from_keyfile function requires the the Exec line in the keyfile to be an executable (in the context of the current environment, so the portal). Flatpak apps do not have the executable on the host, but use `flatpak run`. The portal rewrites those Exec lines, but it did so after calling g_desktop_app_info_new_from_keyfile, so it would fail if whatever the Exec line specified was not a valid executable on the host. Resolves: flatpak#1674

swick · 2025-03-25T17:56:08Z

#1682 might fix the issue here

mcatanzaro · 2025-03-26T00:12:54Z

I was using flatpak when I tested this earlier today. For example:

[Desktop Entry]
Exec=flatpak run --command=epiphany 'org.gnome.Epiphany.Devel' --application-mode --profile=/home/mcatanzaro/.var/app/org.gnome.Epiphany.Devel/data/org.gnome.Epiphany.Devel.WebApp_5442e2b64fa09764b9f593867e59a97292c84059 'https://github.com/flatpak/xdg-desktop-portal/issues/1674#issuecomment-2752032535'

this works perfectly fine with xdg-desktop-portal 1.20.0, same version that Satvik is using.

eyekay-gh · 2025-03-26T04:24:20Z

I don't have anything technical to add, but I can confirm that if I use

[Desktop Entry]\nExec = flatpak run net.codelogistics.webapps {}\nTerminal=false\nType=Application\nCategories=Network;

in the call to dynamic_launcher_install, it does install a desktop file. The desktop file itself it useless though, because it calls 'flatpak' within the flatpak:

[Desktop Entry]
Exec=flatpak run --command=flatpak 'net.codelogistics.webapps' run net.codelogistics.webapps webapp-f24ddc93-a402-4ee3-9b76-9ed204e25df5
Terminal=false
Type=Application
Categories=Network;
Name=Google
Icon=/home/satvikp/.local/share/xdg-desktop-portal/icons/128x128/net.codelogistics.webapps.webapp-f24ddc93-a402-4ee3-9b76-9ed204e25df5.png
X-Flatpak=net.codelogistics.webapps

This is on xdg-desktop-portal 1.20.0.

swick · 2025-03-26T10:43:34Z

Right, if you replace webapps with true, it will work for flatpak but on the host it won't because the Exec line is not re-written there.

Anyway, this confirms that #1682 will fix the issue.

mcatanzaro · 2025-03-26T15:36:34Z

That won't fix the issue with Epiphany because it's implausible that the user does not have flatpak installed and executable. I've asked the Epiphany user to report a new bug.

swick · 2025-03-26T15:49:33Z

e: Do we know if the user is running Epiphany on the host or in a flatpak, and what the exact desktop entry is?

eyekay-gh · 2025-03-26T16:09:53Z

Anyway, this confirms that #1682 will fix the issue.

Thank you. Should I replace webapps with true in the meantime? Will that workaround work after your PR has been merged as well? Because once it is merged and released I will have Arch users who have that fix within a week and also Debian users who won't have it for over a year.

Also, I did some testing on installing web apps through Epiphany as well. When using Epiphany installed through Flatpak, I cannot install web apps, with the same error message as the user in the epiphany gitlab issue did.

Epiphany through my distro package (Debian) can install web apps in both the cases where Flatpak is and is not installed. The desktop entry is:

[Desktop Entry]
Exec=epiphany --application-mode "--profile=/home/satvikp/.local/share/org.gnome.Epiphany.WebApp_2b681c0a24baff8899d7163cc7f805c75e1f44e4" https://www.google.com/
StartupNotify=true
Terminal=false
Type=Application
Categories=GNOME;GTK;
StartupWMClass=org.gnome.Epiphany.WebApp_2b681c0a24baff8899d7163cc7f805c75e1f44e4
X-Purism-FormFactor=Workstation;Mobile;
Name=Google
Icon=/home/satvikp/.local/share/xdg-desktop-portal/icons/192x192/org.gnome.Epiphany.WebApp_2b681c0a24baff8899d7163cc7f805c75e1f44e4.png

mcatanzaro · 2025-03-26T16:28:13Z

e: Do we know if the user is running Epiphany on the host or in a flatpak, and what the exact desktop entry is?

This user is running in a flatpak, so I think the non-flatpak example provided by eyekay in the comment above is not relevant.

It's impossible to ask the user to provide an exact desktop entry since we can only check the generated desktop file if the portal does not reject the request. Would be very helpful if xdg-desktop-portal could print the rejected desktop file with g_debug(). Since eyekay is able to reproduce the problem, we could ask him to run a custom build of xdg-desktop-portal to test, though.

When I create a web app successfully, the Exec line looks like:

[Desktop Entry]
Exec=flatpak run --command=epiphany 'org.gnome.Epiphany.Devel' --application-mode --profile=/home/mcatanzaro/.var/app/org.gnome.Epiphany.Devel/data/org.gnome.Epiphany.Devel.WebApp_5442e2b64fa09764b9f593867e59a97292c84059 'https://github.com/flatpak/xdg-desktop-portal/issues/1674#issuecomment-2752032535'

eyekay, are you sure that you have Epiphany installed on your host system when you test installing the web app using the Flatpak version of Epiphany? If so, then we know #1682 will not fix the Epiphany issue.

eyekay-gh · 2025-03-26T16:39:38Z

I didn't have Epiphany on the host when I tried the Flatpak version.

Since eyekay is able to reproduce the problem, we could ask him to run a custom build of xdg-desktop-portal to test, though.

I tried doing it myself, but I couldn't figure out where it was being printed, if at all. If you can share the modified source and let me know where to look for the output, I'll be happy to help.

swick · 2025-03-26T16:45:34Z

This user is running in a flatpak, so I think the non-flatpak example provided by eyekay in the comment above is not relevant.

I feel like we're talking past each other.

On the host this shouldn't be a problem because the thing you write in Exec is a thing that got installed on the host, and it doesn't get changed by the portal.

On flatpak, the problem is that the thing you write in Exec is not visible on the host (or if it is, then it's by accident). We check that it's executable before we rewrite it to flatpak run .... This is the bug. We should check this only after rewriting.

When I create a web app successfully, the Exec line looks like:

I'm going to guess that you also installed epiphany on the host.

swick · 2025-03-26T16:46:19Z

I tried doing it myself, but I couldn't figure out where it was being printed, if at all. If you can share the modified source and let me know where to look for the output, I'll be happy to help.

The most helpful thing would be to test the PR. If it doesn't fix things, we can try to dig deeper.

eyekay-gh · 2025-03-26T17:12:25Z

I don't know how I to do that :( I don't know how to build a debian package from your PR and I'm not sure how else I can test it.

mcatanzaro · 2025-03-26T17:53:42Z

I didn't have Epiphany on the host when I tried the Flatpak version.

OK, then swick is probably correct. Please test it again now that you do have it installed, and if the bug goes away, then we know swick's diagnosis is correct.

eyekay-gh · 2025-03-26T18:51:34Z

It does work now, yes

The g_desktop_app_info_new_from_keyfile function requires the the Exec line in the keyfile to be an executable (in the context of the current environment, so the portal). Flatpak apps do not have the executable on the host, but use `flatpak run`. The portal rewrites those Exec lines, but it did so after calling g_desktop_app_info_new_from_keyfile, so it would fail if whatever the Exec line specified was not a valid executable on the host. Resolves: flatpak#1674

eyekay-gh added the bug label Mar 19, 2025

swick linked a pull request Mar 25, 2025 that will close this issue

dynamic-launcher: Check Desktop file after AppInfo can rewrite Exec #1682

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Cannot create/ install dynamic launchers #1674

Cannot create/ install dynamic launchers #1674

eyekay-gh commented Mar 19, 2025

swick commented Mar 21, 2025

eyekay-gh commented Mar 21, 2025

swick commented Mar 21, 2025

eyekay-gh commented Mar 25, 2025

mcatanzaro commented Mar 25, 2025

swick commented Mar 25, 2025

mcatanzaro commented Mar 25, 2025

swick commented Mar 25, 2025

hfiguiere commented Mar 25, 2025

swick commented Mar 25, 2025

swick commented Mar 25, 2025

mcatanzaro commented Mar 26, 2025

eyekay-gh commented Mar 26, 2025

swick commented Mar 26, 2025

mcatanzaro commented Mar 26, 2025

swick commented Mar 26, 2025 •

edited

Loading

eyekay-gh commented Mar 26, 2025

mcatanzaro commented Mar 26, 2025

eyekay-gh commented Mar 26, 2025

swick commented Mar 26, 2025

swick commented Mar 26, 2025

eyekay-gh commented Mar 26, 2025

mcatanzaro commented Mar 26, 2025

eyekay-gh commented Mar 26, 2025

Cannot create/ install dynamic launchers #1674

Cannot create/ install dynamic launchers #1674

Comments

eyekay-gh commented Mar 19, 2025

Operating System

XDG Desktop Portal version

XDG Desktop Portal version (Other)

Desktop Environment

Desktop Environment (Other)

Expected Behavior

Current Behavior

Steps to Reproduce

Anything else we should know?

swick commented Mar 21, 2025

eyekay-gh commented Mar 21, 2025

swick commented Mar 21, 2025

eyekay-gh commented Mar 25, 2025

mcatanzaro commented Mar 25, 2025

swick commented Mar 25, 2025

mcatanzaro commented Mar 25, 2025

swick commented Mar 25, 2025

hfiguiere commented Mar 25, 2025

swick commented Mar 25, 2025

swick commented Mar 25, 2025

mcatanzaro commented Mar 26, 2025

eyekay-gh commented Mar 26, 2025

swick commented Mar 26, 2025

mcatanzaro commented Mar 26, 2025

swick commented Mar 26, 2025 • edited Loading

eyekay-gh commented Mar 26, 2025

mcatanzaro commented Mar 26, 2025

eyekay-gh commented Mar 26, 2025

swick commented Mar 26, 2025

swick commented Mar 26, 2025

eyekay-gh commented Mar 26, 2025

mcatanzaro commented Mar 26, 2025

eyekay-gh commented Mar 26, 2025

swick commented Mar 26, 2025 •

edited

Loading