chromium has the ability to create desktop files that are shortcuts to websites, and it opens them in a standalone window, with a custom icon and minimal chrome (webapp mode).
Bug #1732482 tracks why this doesn’t work just yet in chromium, but with minimal changes I have managed to have it create said desktop files under $HOME/snap/chromium/current/.local/share/applications. This is not very useful though, as gnome shell (and other desktop environments) is not expecting desktop files there (it looks in $XDG_DATA_DIRS).
Appending $HOME/snap/chromium/current/.local/share to $XDG_DATA_DIRS does the trick, but it’s just a hack. I wonder if we could devise a proper mechanism for snaps in general to expose desktop files that they create for DEs to see. Or is it a terrible idea security-wise?
This is tricky because if the snap can arbitrarily write to anything in $XDG_DATA_DIRS, then it can escape confinement by creating a desktop file with a crafted Exec line. I’m not sure how to solve this, but it is clear that snapd needs to be involved to sanitize the desktop file. One idea might be snapd userd gain a ‘register desktop file’ DBus API that snaps could call (perhaps via a helper command in a similar manner as the xdg-settings ideas). This obviously requires that snaps be modified to use it.
I don’t see a clear path forward so I definitely think it needs to be discussed further and I think it might be interesting if someone did some investigation on the major browsers to see if there are any commonalities. Would need @niemeyer and @mvo to comment on a general direction at the very least.
I like that the Snap package of Chromium blocks access to my .ssh folder from the browser. The Flatpak “home” access still allows hidden file and folder access.
However, the lack of this “web app” feature is a blocker to me adopting the Snap version of Chromium. Most of the “apps” I use throughout the day are web apps. I use this Chromium feature to add them to my Gnome dock and switch between them frequently using Super-1, Super-5, etc.
Also, this feature is very natural to use on Chromebooks, so it’s appealing to Ubuntu users like me who switch back and forth between and Chromebook are trying to keep our the experience consistently.
I’ll try Flatpak and see if it offers this feature.
It seems like a reasonable feature, and useful to more than just Chrome. Other (currently unconfined) examples I can see on my system include Wine creating desktop files for installed Windows apps, and Steam creating (optionally) creating desktop files for installed games. So it definitely seems like a
I have a few thoughts here:
This might be a candidate for an xdg-desktop-portal API. If we make it snap specific, then we need to convince the upstream to carry a potentially invasive snap specific patch. That API may call out to userd or the session agent to complete the task when the client is a snap.
The API would need to copy the desktop file plus dependencies somewhere the snap can not write to. This includes icons.
We’d definitely need to implement image file validation for this. All the existing cases where we expose images from snaps to the host involve files distributed as part of the snap, which can be checked by review tools. For a feature like this, the app will usually want a new icon for each desktop file: presumably created in writeable storage. So snapd+tools would be the only line of defence in deciding whether the image file is malicious.
Both Wine and Steam both install new icons to ~/.local/share/icons/hicolor for the new desktop files they create, potentially including multiple sizes. This should be a consideration in the shape of the API.
If we use the snap’s existing desktop file as a template, what fields should it be allowed to replace? At a minimum, it probably needs to be:
arguments to the Exec line
We’d want some way to clean these files up when the snap is uninstalled. We’ve already got snapd poking around the users’ home directories on uninstall, so perhaps it could handle this too. Alternatively, it could be handed off to the session agent: either to handle immediately, or when the user next logs in.
will any of these applications want to create desktop files with actions (i.e. additional [Desktop Action foo] sections with their own display name and command line)?
do we care about translations? These additional desktop entries are created per-user, so perhaps the app can just produce strings in the user’s native language from the start. This appears to be what Wine and Steam do (or perhaps they just produce English up front?).
this one is probably Chrome specific: does the application want to register mime types as being handled by the new desktop file? I know there is a navigator.registerProtocolHandler web API, so does Chrome do anything to a webapp’s desktop file if this gets called? Does that mean it might want to modify the desktop file after it has been created?
I tried manually fixing the paths and putting the file in ~/.local/share/applications, but I end up with a generic icon and all such apps gets grouped together under a single icon instead of appearing individually.
This is an essential feature for me, so I’m giving on the Chromium snap until this bug is fixed (or I find a workaround)