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

Bug #1732482 reported by Ken VanDine
364
This bug affects 71 people
Affects Status Importance Assigned to Milestone
chromium-browser (Ubuntu)
Fix Released
Medium
Nathan Teodosio

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.

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.

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.

Revision history for this message
Julian Alarcon (julian-alarcon) wrote :

I still have the same issue installing Youtube Music Web app (https://music.youtube.com/) in Ubuntu 22.04.

Revision history for this message
iGadget (igadget) wrote :

Yup, same with any PWA (or site). After almost 5(!!!) years, still no progress here. Google being the obvious winner since that's the *only* browser remaining where PWA's 'just work'. Would really appreciate a response to #26.

Olivier Tilloy (osomon)
Changed in chromium-browser (Ubuntu):
assignee: Olivier Tilloy (osomon) → nobody
Revision history for this message
Julian Alarcon (julian-alarcon) wrote :

For Youtube Music, I ended up setting the file like this:

```
#!/usr/bin/env xdg-open
[Desktop Entry]
Version=1.0
Terminal=false
Type=Application
Name=YouTube Music
Exec=/snap/bin/chromium --profile-directory=Default --app-id=cinhimbnkkaeohfgghhklpknlkffjgod
Icon=/home/MYUSER/snap/chromium/common/chromium/Default/Web Applications/Manifest Resources/cinhimbnkkaeohfgghhklpknlkffjgod/Icons/256.png
StartupWMClass=crx_cinhimbnkkaeohfgghhklpknlkffjgod
```

And to be available in the Applications launcher, I copied the file to ~/.local/share/applications/

Changed in chromium-browser (Ubuntu):
status: Triaged → In Progress
assignee: nobody → Nathan Teodosio (nteodosio)
description: updated
Changed in chromium-browser (Ubuntu):
status: In Progress → Fix Committed
Revision history for this message
Nathan Teodosio (nteodosio) wrote (last edit ):

This is supposedly fixed in edge and beta channels (x86 and ARMv8):

    snap refresh --edge chromium
    #Or
    snap refresh --beta chromium
    #And then connect the required plugs:
    snap connect chromium:dot-local-share-applications
    snap connect chromium:dot-local-share-icons

Your report of whether this works or not would be very welcome.

Revision history for this message
WBGSReject (wbgsreject) wrote :

I have Chromium on Ubuntu 22.04.3 LTS and Chromium 116.0.5845.187 (Official Build) snap (64-bit).

I can confirm that my PWA does now install on my desktop. I have to right-click the icon and select "Allow Launching" and then it works correctly.

Thanks to everyone who worked on this.

My PWA used for testing this is at: https://signals.rotor-rig.com/

Ian

Revision history for this message
Julian Alarcon (julian-alarcon) wrote :

A. Tested https://signals.rotor-rig.com/ with stable version snap x64 (117.0.5938.88):
File chrome-pdplehbldmmknfihajdehomkoigcbhib-Default.desktop was created in ~/Desktop
#!/usr/bin/env xdg-open
[Desktop Entry]
Version=1.0
Terminal=false
Type=Application
Name=Signals
Exec=/snap/bin/chromium --profile-directory=Default --app-id=pdplehbldmmknfihajdehomkoigcbhib
Icon=chrome-pdplehbldmmknfihajdehomkoigcbhib-Default
StartupWMClass=crx_pdplehbldmmknfihajdehomkoigcbhib

No file was created in ~/.local/share/applications . So, it's not possible to find it in the launcher

File icon in desktop has no icon and allow launching needs to be clicked, worked after that. App had no icon.

B. Tested in snap beta (118.0.5993.11)
File was not created in ~/Desktop , so no Desktop Icon

File chrome-pdplehbldmmknfihajdehomkoigcbhib-Default.desktop was created in ~/.local/share/applications
#!/usr/bin/env xdg-open
[Desktop Entry]
Version=1.0
Terminal=false
Type=Application
Name=Signals
Exec=/snap/bin/chromium --profile-directory=Default --app-id=pdplehbldmmknfihajdehomkoigcbhib
Icon=chrome-pdplehbldmmknfihajdehomkoigcbhib-Default
StartupWMClass=crx_pdplehbldmmknfihajdehomkoigcbhib

App was available in Ubuntu Launcher.
C. Tested in edge (118.0.5993.11)
Same behavior than Beta, file in ~/Desktop was not created but it was created in ~/.local/share/applications

In all 3 cases the dock never showed the App icon when I opened the app but the Chromium Icon. I don't know if this could be fixed as if I open any PWA and then I want to open Chromium, it will show the PWA window and not open a Chromium window.

Revision history for this message
Nathan Teodosio (nteodosio) wrote :

Thanks for testing!

Julian, I think you already know that and just wanted to perform thorough testing, but in case it was not clear, the fix is not yet in stable.

Yet you noted something in test case A:

> File chrome-pdplehbldmmknfihajdehomkoigcbhib-Default.desktop was created in ~/Desktop

Did you expect that? I'd assume that is the wrong behavior but then I don't use PWAs.

What you describe in cases B and C is (what I believe to be) the expected behavior.

> In all 3 cases the dock never showed the App icon when I opened the app but the Chromium Icon. I don't know if this could be fixed as if I open any PWA and then I want to open Chromium, it will show the PWA window and not open a Chromium window.

That is a known issue but with Gnome Shell (c.f. LP:#2007652 for that); it doesn't happen in other desktop environments (tested Unity, Icewm).

Revision history for this message
Nathan Teodosio (nteodosio) wrote :

WBGSReject, you seem to have tested stable! And apparently you observed the same as Julian (#34) in test A. So I also extend my question to you: Do you expect the PWA on the desktop or as a launcher?

I'll be investigating if there is any consensus on that, but otherwise I might simply combine the two approaches, namely creating both a desktop launcher (~/Desktop) and a dock/activities/menu launcher (~/.local/share/applications).

Revision history for this message
WBGSReject (wbgsreject) wrote : Re: [Bug 1732482] Re: [snap] doesn't properly save desktop files for "create shortcuts" action

Nathan - yes, I checked stable only. When I first reported this, the
desktop icon didn't work at all on stable, so I was pleased to see it
working now.

I did see the app icon on the desktop though - that seems to differ from
Julian's tests.

Seeing it work on the desktop was good. Of course it would be even better
if it worked as a launcher. Having the PWA install to both desktop and
launcher might be confusing. When an Ubuntu application is installed it
appears as a launcher, so that is what I think would be best for a PWA too
IMHO.

On Fri, 22 Sept 2023 at 13:51, Nathan Teodosio <email address hidden>
wrote:

> WBGSReject, you seem to have tested stable! And apparently you observed
> the same as Julian (#34) in test A. So I also extend my question to you:
> Do you expect the PWA on the desktop or as a launcher?
>
> I'll be investigating if there is any consensus on that, but otherwise I
> might simply combine the two approaches, namely creating both a desktop
> launcher (~/Desktop) and a dock/activities/menu launcher
> (~/.local/share/applications).
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1863897).
> https://bugs.launchpad.net/bugs/1732482
>
> Title:
> [snap] doesn't properly save desktop files for "create shortcuts"
> action
>
> Status in chromium-browser package in Ubuntu:
> Fix Committed
>
> 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.
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1732482/+subscriptions
>
>

Changed in chromium-browser (Ubuntu):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.