Call for testing: chromium-browser deb to snap transition

snap
21

Regarding password-store backends, for some people ability to pass persistent chromium flags would help

22

I see, that’s annoying indeed. As I wrote in an earlier comment, I would have expected D-Bus activation to work in this context. @jdstrand: can you shed some light on this problem? The chromium launcher script talks to D-Bus (session bus) to guess whether a password manager daemon is available for the browser to talk to, but it appears activation doesn’t work if said daemon is not yet running. Is that expected? Is there an obvious mistake in that launcher script?

23

@oSoMoN I’ve seen this problem where the session service isn’t started by D-Bus activation because it’s being activated by a confined process and Apparmor (or maybe systemd I don’t remember) isn’t sure what confinement the service launched will be under and so it doesn’t get activated. See https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1749000

The fix for that was to add AssumedAppArmorLabel=unconfined to the service file for netplan, perhaps kwallet needs to do the same thing? I’m assuming kwallet runs unconfined

2 Likes
24

Yes, I confirmed that adding AssumedAppArmorLabel=unconfined to kwallet service make dbus activation works again

Considering that almost all services don’t have Apparmor profile thus run unconfined then we can conclude that dbus activation is generally broken for snaps. Moreover patching every service, either upstream or in every distro separately sound like herculean if not impossible task. Maybe you should ask dbus upstream to revert https://cgit.freedesktop.org/dbus/dbus/commit/?id=dc25979eb or fix it some other way?

1 Like
25

And I can confirm that AssumedAppArmorLabel=unconfined fixes D-Bus activation of both gnome-keyring-daemon and kwalletd5 from within a snap.

2 Likes
26

I’ve started another topic to discuss broken D-Bus activation. Hopefully there exists a solution that doesn’t involve patching every single D-Bus service file out there.

27

For some reason my chromium profile does not import from .config/chromium when I start the snap chromium. How does one go about importing their profile manually?

28

well, it looks like I was able to restore access to saved passwords via snap connect chromium:password-manager-service

29

Yes, the connection should have happened automatically, sorry for the inconvenience (this is being tracked by bug #1849160).

As for the profile import, it happens only the first time the chromium snap is run, and it basically copies the contents of $HOME/.config/chromium to $SNAP_USER_DATA/.config/chromium.

30

It seems like the Chromium snap takes longer to start than the .deb and support for desktop “app” generation through .desktop files remains completely broken.

Reference: How to expose desktop files created by snaps to the DE?

If you go to “More Tools… Create Shortcut / Open In New Window”, you should end up with a new “app” that you can find in the launcher and will have it’s own icon and handling when added to the dock.

The flow to create a new “app” finishes without error in the Snap now, yet no app is found in the launcher and the new app is grouped with the original Chromium app in
the dock.

I tried to workaround this issue by installing the “.deb” instead of the “.snap”, but this did
not work. The .deb file redirects to install the snap instead.

This is very frustrating. Now to get Chromium working again on Ubuntu I either have to track down a non-snap / non-deb version or switch to a Linux distribution with non-broken Chromium package.

1 Like
31

The snap packaging breaks the “Open In Firefox” extension:

https://github.com/andy-portmen/native-client/issues/79

The issue is that the snap package does not use the standard ~/.config" directory to store files. The “native client” installer for the extension installs files into ~/.config/chromium, but this fails because it’s not the directory used by the browser.

32

The workaround for the broken Chromium snap and the “.deb” package that redirects to it is to install the “ungoogled-chromium” package, which will works almost exactly the same except for some privacy improvements and is still available in the non-broken .deb format:

https://launchpad.net/~braewoods/+archive/ubuntu/ungoogled-chromium

The installed binary and icon are identical to “Chromium” branding.

33

This is tracked by bug #1732482.

34

Thanks for raising this issue here. I commented on the upstream bug.

35

chromium.launcher keep spawning sleep 60

36

It’s not possible to share files through /tmp. The snap chromium doesn’t have access to /tmp and maps /tmp to /tmp/snap.chromium/tmp. The regular users needs super user permissions to access /tmp/snap.chromium/tmp. This is a really sad thing.

37

This was an undesirable side-effect of the initial implementation of bug #1864901, but it should now be fixed with the latest update.

38

This is being discussed in a separate thread: Sharing files via /tmp.

39

$ snap info chromium
name: chromium
summary: Chromium web browser, open-source version of Chrome
publisher: Canonical✓
store-url: https://snapcraft.io/chromium
contact: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bugs?field.tag=snap
license: unset
description: |
An open-source browser project that aims to build a safer, faster, and more
stable way for all Internet users to experience the web.
commands:

  • chromium.chromedriver
  • chromium
    snap-id: XKEcBqPM06H1Z7zGOdG5fbICuf8NWK5R
    tracking: latest/stable
    refresh-date: 3 days ago, at 21:41 +03
    channels:
    latest/stable: 81.0.4044.129 2020-04-29 (1135) 161MB -
    latest/candidate: 81.0.4044.129 2020-04-28 (1135) 161MB -
    latest/beta: 83.0.4103.23 2020-04-25 (1125) 163MB -
    latest/edge: 84.0.4128.3 2020-04-29 (1136) 164MB -
    installed: 81.0.4044.129 (1135) 161MB -

i can see a process right now. launcher

40

The fact that there’s one process running right now is perfectly normal, the problem was when multiple instances of it were kept running after exiting chromium.