Call for testing: chromium-browser deb to snap transition

[juliank]

I wanted to ask about native messaging (https://developer.chrome.com/extensions/nativeMessaging). It’s a terrible idea where you register programs on the host with the browser in a json file and the browser than starts them and you can communicate with them.

The KeePassXC browser integration is making use of that, and this obviously breaks with snaps, whether Chromium or Firefox. I imagine it would be possible to write like a native messaging bridge and have a native-messaging interface in the snaps to support this, but I’m uncertain if anyone has looked at that at all.

[coeur-noir]

[quote=“oSoMoN, post:7, topic:11179”]
Why would you want to not install the snap version? Does it break an existing workflow for you?[/quote]
Maybe because :
⋅ snap wastes disk space,
⋅ confinement is more pain than gain in « simple » desktop usage,
⋅ forces user to otherwise organize his⋅her personal data to make them still available through snap app’,
⋅ theming issues might also break some workflow or habits.

Snap can be installed without confinement --classic but then losing their safety benefit which sounds like a misuse.

[gunnarhj]

@gunnarhj

How about confining e.g. these paths:

/usr/lib/pepperflashplugin-nonfree/libpepflashplayer.so
/usr/lib/adobe-flashplugin/libpepflashplayer.so

@oSoMoN, @jdstrand: If that can be fixed, I envision a change along these lines:

https://git.launchpad.net/~gunnarhj/chromium-browser/+git/snap-from-source/commit/?id=6ccbb389

[mark-pcnetspec]

IMHO backporting this change to the 18.04 LTS would undermine trust, there is no way to gauge whether LTS users signed up for snaps … indeed I’d say they absolutely did not. 19.10 of course still belongs to Canonical/Ubuntu, but 18.04 does NOT, it now belongs to its users.

[P_IH]

I’m using 19.10. After the upgrade to snap I get this error message when I open the
https://extensions.gnome.org/ page
“Although GNOME Shell integration extension is running, native host connector is not detected. Refer documentation for instructions about installing connector.”

[paulw2u]

@P_IH, that’s a known issue, bug 1741074.

[P_IH]

Thanks added me to the list of affected persons.
Is there a bog on the theme problem?

[mohan-ram]

I know this is little off topic, but some what relatable. FF snap also does not use Yaru theme, looks to be using Adwaita.

[mohan-ram]

In that light using Ambiance and Radiance themes snap versions of Chromium and Firefox look like they take the theme just fine.

[jonathon]

@oSoMoN

when running the snap for the first time, an existing chromium user profile in $HOME/.config/chromium will be imported (provided there is enough disk space)

How does this work in a multi-user networked environment?

Are snaps usable with e.g. Kerberised NFS home directories?

[jyaku]

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.

[mikhailnov]

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.

1. 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?

2. 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?

3. 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

4. what about updating in chroot where snapd is not running, how will you handle it?

[oSoMoN]

@coeur-noir

⋅ snap wastes disk space,

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 -

[oSoMoN]

@coeur-noir

⋅ theming issues might also break some workflow or habits.

Agreed, theming issues should be investigated and fixed. The CSD issue is tracked by bug #1800260.

[oSoMoN]

@juliank

It’s a terrible idea where you register programs on the host with the browser in a json file and the browser than starts them and you can communicate with them.

I like your description of native messaging .
There’s bug #1741074 to track the issue, but no practical solution so far.

[oSoMoN]

@P_IH

Is there a bog on the theme problem?

bug #1800260

[jdstrand]

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.

[gunnarhj]

@jdstrand

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.

[jdstrand]

@gunnarhj

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).

[gunnarhj]

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.