Call for testing: chromium-browser deb to snap transition

bug #1800260

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.

2 posts were merged into an existing topic: Please, do not use snap into UBUNTU, it’s too early

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

Yes, widevine works here, see this thread on the snapcraft forum.

A bump for a very visible (invisible?) regression from the deb :smiley: Bug #1821765 “[snap] Missing icon in indicator” : Bugs : chromium-browser package : Ubuntu

I have apt installing some packages, and thus holding the lock. I have snap installed yet it tries to install it (or check?). I have Firefox on screenshot but it doesn’t matter. Probably the correct action is just do snap install if apt is busy

snapd and apt are two totally independent packaging systems, the lock for the former doesn’t affect the latter, and vice versa. If the problem persists please report it by running ubuntu-bug gnome-software, and please try to keep the feedback on this thread related to the chromium snap. Thanks!

1 Like

Over the past couple of days I’ve tested the installation of Chromium on each of the Ubuntu flavours using that day’s ISO. Unfortunately, I don’t currently have the necessary resources to install to disk or VM so the installation of Chromium was done in a live session.

Installation completed quickly for Ubuntu but was very slow for the flavours as I saw an “INFO Waiting for restart…” message displayed for some time. Is this due to Ubuntu already having snaps installed and configured? However, installation was successful in every case.

Further to my comment in a previous post in this thread, I see that on Ubuntu and Ubuntu Budgie, the mouse pointer when hovering over a link is a black upward pointing hand but on Ubuntu MATE, Kubuntu, Lubuntu and Xubuntu it is a rather retro looking white left pointing hand. Is this something that can be fixed?

1 Like

Why is the removable-media connection not enabled by default?

1 Like

Thank you for your testing and feedback Paul, this is much appreciated!

The slow installation observed on flavours is indeed because snapd isn’t installed and configured there, whereas it is installed and the core snaps are preseeded on Ubuntu proper.

Could you please file a bug for the mouse pointer issue? I’ll certainly investigate to try and fix it.

1 Like

Auto-connection for the removable-media interface has been requested, the request has to go through the approval process by store moderators now.

Done.

Bug 1833611.

In a new installation of EOAN it’s not possible to install gnome extensions in Chromium.
You get this error message
“Although GNOME Shell integration extension is running, native host connector is not detected.” Refer documentation for instructions about installing connector."
The method advised in the instruction “GNOME Shell integration for Chrome Installation Guide”
$ sudo apt-get install chrome-gnome-shell
isn’t working.