[snap] doesn't properly save desktop files for "create shortcuts" action

Bug #1732482 reported by Ken VanDine on 2017-11-15
190
This bug affects 35 people
Affects Status Importance Assigned to Milestone
chromium-browser (Ubuntu)
Medium
Olivier Tilloy

Bug Description

For chrome apps, the create shortcuts action should create desktop files but it doesn't. I suspect it has something to do with paths.


tracking: candidate
installed: 62.0.3202.94 (123) 246MB -

Olivier Tilloy (osomon) wrote :

With logging enabled, when trying to create a shortcut I'm seeing this:

LaunchProcess: failed to execvp:
xdg-desktop-menu
LaunchProcess: failed to execvp:
xdg-desktop-menu
LaunchProcess: failed to execvp:
xdg-icon-resource
[21693:21829:1115/175326.882133:WARNING:shell_integration_linux.cc(319)] Could not install icon chrome-nbpndmhhdfecmpfahflnahbbdpihnadk-Default.png at size 32.
LaunchProcess: failed to execvp:
xdg-icon-resource
LaunchProcess: failed to execvp:
xdg-icon-resource
[21693:21831:1115/175326.885379:WARNING:shell_integration_linux.cc(319)] Could not install icon chrome-nbpndmhhdfecmpfahflnahbbdpihnadk-Default.png at size 32.
[21693:21829:1115/175326.887645:WARNING:shell_integration_linux.cc(319)] Could not install icon chrome-nbpndmhhdfecmpfahflnahbbdpihnadk-Default.png at size 48.
LaunchProcess: failed to execvp:
xdg-icon-resource
[21693:21831:1115/175326.891419:WARNING:shell_integration_linux.cc(319)] Could not install icon chrome-nbpndmhhdfecmpfahflnahbbdpihnadk-Default.png at size 48.
LaunchProcess: failed to execvp:
xdg-icon-resource
[21693:21829:1115/175326.894292:WARNING:shell_integration_linux.cc(319)] Could not install icon chrome-nbpndmhhdfecmpfahflnahbbdpihnadk-Default.png at size 128.
LaunchProcess: failed to execvp:
xdg-icon-resource
[21693:21831:1115/175326.896715:WARNING:shell_integration_linux.cc(319)] Could not install icon chrome-nbpndmhhdfecmpfahflnahbbdpihnadk-Default.png at size 128.
LaunchProcess: failed to execvp:
xdg-icon-resource
[21693:21829:1115/175326.906654:WARNING:shell_integration_linux.cc(319)] Could not install icon chrome-nbpndmhhdfecmpfahflnahbbdpihnadk-Default.png at size 256.
LaunchProcess: failed to execvp:
xdg-icon-resource
[21693:21831:1115/175326.908762:WARNING:shell_integration_linux.cc(319)] Could not install icon chrome-nbpndmhhdfecmpfahflnahbbdpihnadk-Default.png at size 256.
LaunchProcess: failed to execvp:
xdg-desktop-menu
LaunchProcess: failed to execvp:
xdg-desktop-menu

Changed in chromium-browser (Ubuntu):
status: New → Confirmed
assignee: nobody → Olivier Tilloy (osomon)
importance: Undecided → Medium
Olivier Tilloy (osomon) wrote :

If I add usr/bin/xdg-desktop-menu and usr/bin/xdg-icon-resource to the snap, the errors go away, and indeed a desktop file is created in $HOME/snap/chromium/current/.local/share/applications/.

These desktop files are not marked executables, so double-clicking on them in nautilus won't work. After marking them executable, interestingly some of them work, and some don't (they just open an empty browser window with all its chrome).
An example of a shortcut that works is https://html5test.com. One that doesn't is https://example.org.

Olivier Tilloy (osomon) wrote :

And now the shortcut for https://example.org started working, mysteriously.

Olivier Tilloy (osomon) wrote :

Desktop files in $HOME/snap/chromium/current/.local/share/applications/ are not very useful on a classic desktop, as gnome-shell (or others DEs) won't find them there.
We could probably modify the xdg-desktop-menu script to write to a different location. But $HOME/.local/share/applications/ won't work, because the home plug doesn't allow reading/writing to dot folders.

Olivier Tilloy (osomon) wrote :

Appending $HOME/snap/chromium/current/.local/share to $XDG_DATA_DIRS allows gnome shell (and likely other DEs) to see the desktop files and to launch them using the chromium snap. Need to discuss how this can be approached with the snapd team.

Jonas (jonny-boy) wrote :

Any news on this? I am using chromium 66.0.3359.139 (283 stable snap) under Fedora.
The create shortcuts action created a .desktop file under ~/Desktop, which is not useful when using the Gnome shell.
The Exec part in the .desktop file points to /snap/chromium/283/usr/lib/chromium-browser/chromium-browser ...
which is not the right path for my installation. I replaced the path with /var/lib/snapd/snap/bin/chromium and the chrome app is now working after moving it to .local/share/applications manually.

Olivier Tilloy (osomon) wrote :

There's a discussion on the snapcraft forum at https://forum.snapcraft.io/t/how-to-expose-desktop-files-created-by-snaps-to-the-de/2853, but no recent input on it.

Mark Stosberg (markstos) wrote :

I want to highlight that @jonny-boy's comment could be considered a separate-but-related bug. The exec path being written out in these files is not optimal. Here's one that was just used for me:

     /snap/chromium/821/usr/lib/chromium-browser/chrome

Surely it would be better to refer to the "current" version of the package than a fixed version? Wouldn't "/snap/bin/chromium" be ideal here?

Mark Stosberg (markstos) wrote :

I did get a ".desktop" file to work by manually copying it from ~/Desktop to ~/.local/share/applications, on Ubuntu 18.04.

I experimented with making the Exec= paths that didn't include a hard-coded version. I tried "/snap/bin/chromium", "chrome", "chromium" and "/snap/chromium/821/usr/lib/chromium-browser/chrome".

Well, "chrome" just doesn't work because it's not a binary in $PATH. Both "chromium" and "/snap/bin/chromium" will cause new instances of the web app to launch every time. Only if I use the "/snap/chromium/821/usr/lib/chromium-browser/chrome" will the app work as expected: The first click on the icon in the Gnome dock will launch it and the second click will switch to it if it's running already.

I'm glad I got something to work today but it seems like a bug that this feature only works when hard-coded version is included in the path of .desktop files.

Mark Stosberg (markstos) wrote :

Right now ~/snap/chromium/current is a symlink to a specific version of Chromium. So placing icons and desktop files there will break each time Chromium is upgraded unless the files are copied from the previous version-specific directory to the new one.

Olivier Tilloy (osomon) wrote :

It looks like the problem has evolved since it was originally reported.
Desktop files are now correctly created on $HOME/Desktop/, but there are (at least) two problems with their contents:

  - the Exec stanza runs /snap/chromium/861/usr/lib/chromium-browser/chrome directly, i.e. unconfined

  - the exec path contains the revision number for the snap, and consequently will stop working when the snap is updated

Olivier Tilloy (osomon) wrote :

Another problem that was mentioned in duplicate bug #1848126 is that the icons are created in ~/snap/chromium/current/.config/chromium/Default/Extensions/*/*/icons (along with a manifest file), but they are not correctly linked in ~/.local/share/icons/hicolor/, so they cannot be seen by the desktop environment.

Adolfo Jayme (fitojb) on 2019-10-15
Changed in chromium-browser (Ubuntu):
status: Confirmed → Triaged
Meghdad (no149) wrote :

Actually, the shortcuts were leftovers from the correctly working Chromium on Ubuntu 19.04. After I removed the shortcuts, I can't recreate them using the standard procedure anymore.

So yeah, this is the bug.

tags: added: app chrome
Frank Xu (akazadorian) wrote :

There's another problem I'm not sure if is related: even if the icon is well handled, the opened window will not show as an individual one on taskbar - it will still recognized as a window of Chromium itself with a Chromium icon. On the deb version of Chromium is works correctly.

WBGSReject (wbgsreject) wrote :

I opened a bug 1863897 that is now closed as a duplicate of this one which concerned the A2HS (add to home screen) functionality of PWAs (progressive web apps). If you use the A2HS functionality it should create a desktop icon and open the PWA in a Chromium standalone window that looks similar to a desktop application. However as per this bug, it does not work.

To reproduce, there is an MDN page https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps/Add_to_home_screen that links to a PWA that has a A2HS prompt:

https://mdn.github.io/pwa-examples/a2hs/

In the snap version of Chromium the resulting desktop icon is missing and the link does not work. This did previously work in the deb package of Chromium, so I suspect it is caused by the migration to Snap but have not proved it.

Coeur Noir (coeur-noir) wrote :

If the snap chromium is connected to removable-media, the shortcut is correctly placed in ~/Desktop.

But this shortcut does not work, opens chromium on a blank page.

Tested today on UBudgie 19.10 and chromium-snap 80.0.3987.162 (Build officiel) snap (64 bits).

Coeur Noir (coeur-noir) wrote :

Replacing in Exec=

/snap/chromium/1071/usr/lib/chromium-browser/chrome

by

/snap/bin/chromium

allows .desktop to launch chromium on the expected page, but icon is still not set accordingly.

Michel-Ekimia (michel.ekimia) wrote :

Confirmed on 81

Sly Gryphon (sgryphon) wrote :

Not working for me with Chromium 81, snap version, on Ubuntu 20.04. (Testing with music.youtube.com and twitter.com)

Icon is created on the desktop, but:

* Not executable (need to mark it)
* Just opens empty browser page (app does not run); work around from @coeur-noir above, to replace the version-specific path in Exec with /snap/bin/chromium, gets it working
* Icon is not displayed (just red box with no entry circle)

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers