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

Bug #1732482 reported by Ken VanDine
308
This bug affects 58 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 -

Revision history for this message
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
Revision history for this message
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.

Revision history for this message
Olivier Tilloy (osomon) wrote :

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

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
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?

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
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

Revision history for this message
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)
Changed in chromium-browser (Ubuntu):
status: Confirmed → Triaged
Revision history for this message
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
Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
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).

Revision history for this message
Coeur Noir (coeur-noir) wrote :
Revision history for this message
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.

Revision history for this message
Michel-Ekimia (michel.ekimia) wrote :

Confirmed on 81

Revision history for this message
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)

Revision history for this message
iGadget (igadget) wrote :
Revision history for this message
Alan Pope 🍺🐧🐱 🦄 (popey) wrote :

I added a workaround to the askubuntu post.
https://askubuntu.com/a/1266706/612

Revision history for this message
Bart Janssens (bartholomeus-j) wrote :

The workaround is only part of the solution, the link still opens as a tab in regular chromium window rendering it useless. PWA's are still broken for now since they are supposed to launch as a separate 'application' they way it works in the non-snap version of chromium.

Revision history for this message
iGadget (igadget) wrote :

Such a shame users are being pushed towards regular Chrome, since that's the only feasible 'solution' to this bug for most users. Personally, I've completely given up on Chromium for Ubuntu 20.04+.

tags: added: desktop-lts-wishlist
removed: chrome
Revision history for this message
iGadget (igadget) wrote :

@Sebastian Bacher - genuine question: does not a single person in the chromium-snap team use this feature? Because I can't think of any other reason why this regression (when compared to regular chromium) is treated like a 'wishlist' item. Please, enlighten me.

Currently, on any Ubuntu recent Ubuntu version you're forced to use privacy-invading Chrome if you want to use WebApps. Firefox removed the feature (curiously enough, it does work on mobile), chromium-snap crippled it, chromium non-snap is pretty hard to install for most users and leaves you with a(nother) third-party repo on your system. So what's the rationale here?

Revision history for this message
Thomas Carlisle (tcarlisle2012) wrote :

Just quite bit of input. I landed here because of the same issue on Chrome -- not Chromium. Well, my searching first landed me correctly on a bug filed under "Chrome Browser", and that bug was shut down because it was determined a duplicate of this one. And early in this thread it was put to the snap team -- yet what I am seeing is on Chrome and Chrome wasn't uninstalled via snap package.

So no, this was not a duplicate of https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1863897

And this may not have anything to do with snap, and hence why they are not really taking it and doing much.

Revision history for this message
Coeur Noir (coeur-noir) wrote (last edit ):

Still broken today ( chromium as a snap 94.0.4606.81 revision 1781 ) in UbuntuBudgie 20.04

For Ubuntu users at least :

in the Exec line of the .desktop just replace the beginning

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

by

chromium-browser

Better method → https://forum.snapcraft.io/t/desktop-files-for-menu-integration/13115/9?u=coeur-noir

Maybe also look at Web App Manager offered by Mint team.

…and now Firefox will be packaged as a snap, what a sad joke.

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

Other bug subscribers