Call for testing: chromium based on core18


#1

Description

Chromium is an open-source browser project that aims to build a safer, faster, and more stable way for all Internet users to experience the web.

Version 70.0.3538.77 is the latest stable release from Google.

This is a new build based on core18. It has been thoroughly tested internally on all supported Ubuntu releases (from trusty to cosmic), debian testing and fedora 28, and is now open for wider testing.

How to install

snap install chromium --candidate

or, if you’re already using the chromium snap from the stable channel:

snap refresh chromium --candidate

Note that this is an amd64-only build for now, until I figure out and fix build failures on other architectures.

Also note that the snap can coexist with the ubuntu packages. If you wish to remove the ubuntu packages to use solely the snap, you can do:

sudo apt remove “chromium-*”

Specific Tests

I’m interested in your feedback using the snap for your normal browsing activities and workflows, including web development.

Please report any issues you encounter in this thread, especially those that appear to be regressions from the version in the stable channel (which is based on core16). Thanks!


#2

One question, is the candidate/from-source also using core18?

Thanks for this!


#3

candidate/from-source was closed a while ago, all chromium snaps are now built from source.


#4

Ops, didn’t know that! Thanks!

By the way, nothing important, but on Ubuntu 18.04 I’m still seeing different decoration for Chromium windows of different profiles:


Both profiles are using the Classic theme.


#5

Adding to @pachulo comment, using the GTK+ theme is broken in Ubuntu 18.10 with the default Yaru theme… Is this another case of snaps having wrong theming or is it specific to Chromium?


#6

It appears that one profile is configured to use the system title bar and window borders, whereas the other one uses a custom frame. You can change that by browsing to chrome://settings/appearance


#7

This is chromium-specific, when using a custom frame. See bug #1800260.


#8

That was it! Thanks a lot!


#9

This may be not core18 specific (or even chromium specific) but when I open file dialog (i.e. to import bookmarks) and select my {HOME} dir, then I have access denied logged for most my dotfiles. This is especially annoying when aa-notify is running on system as it causes the whole screen being filled with notifications.

Is it possible to explicitly DENY access to all dotfiles in apparmor profile so access to them won’t be logged?

There are also denials for /etc/fstab, /etc/mtab, /run/mount/utab.

This is tested on Ubuntu Bionic with Xfce.


Explicitly DENY acces to dotfiles
#10

That’s not specific to core18 or the chromium snap indeed.
The home interface allows access to the home directory, except for .dotfiles, by design.
@jdstrand, can you comment on the request for explicit denials?


#11

chromium 70.0.3538.110 based on core18 was now promoted to the stable channel for all supported architectures (amd64, i386, arm64, armhf).

Thanks to everyone who took the time to test and provide feedback!


#12

The new version of the chromium snap is not starting for me.

Snap list
Name Version Rev Tracking Publisher Notes
chromium 70.0.3538.110 516 stable canonical✓ -
core 16-2.36.1 5897 stable canonical✓ core
core18 18 442 stable canonical✓ base
gtk-common-themes 0.1-4-g88bc1b2 818 stable canonical✓ -

After a fresh install of the chromium snap, I get the following error:
main.go:224: cannot change mount namespace of snap “chromium” according to change mount (/snap/gtk-common-themes/818/share/icons/Suru /snap/chromium/516/data-dir/icons/Suru none bind,ro 0 0): cannot use “/snap/gtk-common-themes/818/share/icons/Suru” as bind-mount source: not a directory
execl failed: No such file or directory
child exited with status 1

I am on Fedora Silverblue 29, where /snap does not exist.


#13

Just tested on Fedora 29, and I can confirm the problem. This works on Fedora 28.
There’s one similar report on the forum, so it doesn’t seem to be chromium-specific.

I can also reproduce with the libreoffice snap in the candidate channel (based on core18), but not with the one in the stable channel (core16).

@zyga: is that a known issue with fedora 29 / core18 ?


#14

Is there any way to use an older version of the snap, until the problem has been fixed?


#15

Not from the store, all channels have been updated and are built based on core18 now.

You can check whether you still have an old revision in /var/lib/snapd/snaps/. If so, you could install it manually (passing snapd the --dangerous flag).


#16

This is discussed here: Explicitly DENY acces to dotfiles

The first two should go away if you snap connect chromium:mount-observe. It is almost always fine to ignore these (it is noise from libc6). The last is not allowed in standard interfaces (see Namespace awareness of /run/mount/utab (and libmount)).


#17

you could potentially put the older version on a channel branch as a momentary measure on stable/<branch-name> to ensure a fallback to stable is in place with the idea that it could be fixed by when the branch automatically closes.


#18

Sadly it’s hard to ignore when someone uses aa-notify :frowning_face:


#19

Unfortunately I don’t have any older revisions in this folder. It would be nice, if a fallback channel exists, which users could use, until this problem is fixed.


#20

Sorry for the delay. I have re-published an old revision based on core 16 in the stable/core16 channel (version 70.0.3538.77). Note that it’s amd64 only, and I don’t intend to update it, it’s just provided as-is as a workaround for a problem I hope will be fixed very soon on the snapd/Fedora side.

Similarly, I published a core16-based build of the libreoffice snap in the stable/core16 channel. The same disclaimer goes along with it.