I know this is little off topic, but some what relatable. FF snap also does not use Yaru theme, looks to be using Adwaita.
1 Like
In that light using Ambiance and Radiance themes snap versions of Chromium and Firefox look like they take the theme just fine.
How does this work in a multi-user networked environment?
Are snaps usable with e.g. Kerberised NFS home directories?
Yeah it is strange that both browsers show the wrong theme equally. I hope that the bug is fixed for both of them soon.
Your browser being snapped does make much more sense than - say- gnome Calculator.
I don’t like the migration from deb to snap, but I packaged chromium myself and understand why you want to migrate to snap. But there are some important questions.
-
currently I’m able to take any deb package from Ubuntu and make a custom build of it with some modifications, e.g. I once rebuilt Chromium removing user agent patch when web.whatsapp.com stopped understanding Ubuntu’s default user agent. Also, there is a PPA with VA-API enabled builds. How can the same be done with snaps: rebuild, publish in my own repo and install on all machines?
-
I update all office workstations with Ubuntu (XFCE) automatically with system-autoupdate (https://gitlab.com/mikhailnov/system-autoupdate/) in day time, so, when migrating from deb to snap:
2.1) won’t the browser crash after files from deb are removed?
2.2) if the update is done when the browser is running, what will happen with Chromium’s profile? Will a locked version be moved to another directory? What will happen after the original profile in ~/.config/chromium-browser is deleted? Won’t the profile become damaged? -
what about disk space, I have PCs working on 30 GB SSDs and would not like to keep multiple versions of Chromium alongside each other as snapd does by default
-
what about updating in chroot where snapd is not running, how will you handle it?
Not in this specific case, at least:
$ apt show chromium-browser | grep Installed-Size
Installed-Size: 216 MB
$ snap info chromium | grep installed
installed: 75.0.3770.80 (750) 162MB -
2 Likes
Agreed, theming issues should be investigated and fixed. The CSD issue is tracked by bug #1800260.
1 Like
I like your description of native messaging 
.
There’s bug #1741074 to track the issue, but no practical solution so far.
1 Like
Even if the rules were updated, this won’t work because /usr/lib in the snap isn’t /usr/lib on the host due to the mount namespace and separate runtime.
If /usr/lib is problematic, a symlink could help, couldn’t it?
I made this experiment with my deb-Chromium on 19.04:
$ ls -l /usr/*/adobe-flashplugin/libpepflashplayer.so
-rw-r--r-- 1 root root 18894432 maj 27 00:55 /usr/lib/adobe-flashplugin/libpepflashplayer.so
lrwxrwxrwx 1 root root 48 jun 18 10:31 /usr/share/adobe-flashplugin/libpepflashplayer.so -> ../../lib/adobe-flashplugin/libpepflashplayer.so
And a wrapper:
$ cat ~/bin/chromium-browser
#!/bin/sh
FLASHSO=/usr/share/adobe-flashplugin/libpepflashplayer.so
if [ -e $FLASHSO ]; then
FLASHVERSION=$(grep -a -z LNX $FLASHSO | cut -d ' ' -f 2 | sed -e "s/,/./g")
FLASH_OPTIONS="--ppapi-flash-path=$FLASHSO --ppapi-flash-version=$FLASHVERSION"
fi
exec /usr/bin/chromium-browser $FLASH_OPTIONS $@
That works fine.
You mentioned that your experiment is with the deb, but with snaps, there is the runtime environment which is in part comprised of the mount namespace where most of the filesystem is coming from the core snap (/etc, content snaps and a few other things notwithstanding) and in that environment adobe-flashplugin doesn’t exist anywhere. The chromium snap could ship flash (though doesn’t already presumably due to licensing) or provide a content interface to put the files (but this would not be transparent on upgrades).
Ok, I thought it would be an easy fix to make Chromium as snap benefit from the already existing packages which provide the Flash plugin. Now it’s my understanding that I was wrong.
So I give up on this. As @oSoMoN mentioned, EOL for Flash is approaching, why it would be hard to justify a lot of additional work. A minor improvement of Chromium’s (as snap) Flash support has just been committed; let’s consider it done with that.
I can’t help feeling, though, that it’s a bit worrisome that this conceptually simple fix is actually not so simple in practice.
A custom AppArmor profile. Interfaces are all or nothing, for $HOME access, with some built in protection like no access to hidden dirs. Yes you can disconnect the home interface, but then you have no access at all and you have to hunt down specific snap version’s protected “home”… Yes, theres “current” symlink but that means no persistence on update, if you want some dirs persistently available to the snap.
But this is just one example. The ability to have custom, persistent profiles for snaps is of critical importance, IMHO, if snaps are to replace .deb packaged applications (or to be precise, if snaps are to replace non-containerized installations with full filesystem access by default).
I have not tested that use case myself, but the import mechanism is a per-user one, so that part at least should work as expected.
Any plans for making Firefox (and to less extent Thunderbird) also a snap program by default?
1 Like
Anybody made chromium-snap 75 work with widevine ?
one click test here https://bitmovin.com/demos/drm
A bump for a very visible (invisible?) regression from the deb Bug #1821765 “[snap] Missing icon in indicator” : Bugs : chromium-browser package : Ubuntu