Call for testing: chromium-browser deb to snap transition

…at the wrong ones though :slight_smile:

/snap/chromium/958 is a mountpoint, you are looking at the content of a compressed readonly filesystem file that happens to be loop mounted there … the actual size it occupies on disk can be found via:

$ mount | grep chromium\/958
/var/lib/snapd/snaps/chromium_958.snap on /snap/chromium/958 type squashfs (ro,nodev,relatime)

$ ls -lh /var/lib/snapd/snaps/chromium_958.snap
-rw------- 1 root root 154M Nov 26 09:28 /var/lib/snapd/snaps/chromium_958.snap

… indeed, that you have multiple revisions on disk makes it occupy more space in the end but not as significant as it looks like from looking at the mountpoint content :wink:

Also note that desktop snaps are only a fraction of what is in the snap store, on the “snapped-server/cloud-software” or “snapped-iot-software” side many snaps make actual use of the builtin auto-rollback features and self-testing that come for free with the snap package format … sadly you cant have (auto)roll-back features without having the former data and binaries around, so the above is a design requirement.

…and the same goes for home dirs … which is why snaps execute with a versioned home dir pointing to ~/snap/<packagename>/<version>. We allow you to disconnect the home interface at any point in time for any snap (and on some systems it does not get auto-connected at all). To still give an application a proper $HOME to work in even when there is no way to access the real users home they default to this setup. So the difference you see between deb and snap regarding home dirs is also by design…

Chromium snap is unresponsive or 5-10 seconds upon launch, and randomly while in use.

I never saw this issue before installing the snap.

This system is no slouch. 4 cores, 8 threads, 32G ram (16 free)… While I’m waiting for Chromium to respond to my command (click, typed input, whatever), I can run top in a console and there isn’t anything out of the ordinary.

1 Like

I understand the logic for using a sandboxed $HOME, but this means I cannot use Ctrl+L ~/src/someproject/my.patch in the file dialog when I’m trying to attach patches to bugs, which is annoying.

1 Like

Would you mind filing a bug with as many details as possible, so we can start the investigation there?

My feedback after using snap Chromium for ~6 weeks (Kubuntu 19.10):

:grinning: Neat. I almost forget I am using a snap.

Known issue: I encountered the “losing new profile changes (bookmarks in my case) if Chromium updates while it’s running” problem. Until this is fixed I would recommend the snap only to people aware of this risk.

Startup time is fine (old 2011 computer too).

Known issues in Launchpad: mouse cursor changes to odd hand cursor when hovering over links, mouse cursor is a black traditional cursor rather than my preferred white KDE-style cursor.

Fixed recently: brief white flash of GUI elements (e.g. right-click menus) before getting ‘filled in’ was mildly annoying. Presumably related to Nouveau graphics driver.

5 Likes

Thanks for the feedback!

For the issue with chromium being silently updated while it’s running, I recommend turning on the Refresh App Awareness experimental feature, which will prevent exactly that:

snap set core experimental.refresh-app-awareness=true
2 Likes

This should be fixed when this MR is merged: https://gitlab.gnome.org/Community/Ubuntu/gtk-common-themes/merge_requests/17

It’s been sitting there for a while, waiting for someone from the desktop team to review it.

2 Likes

Two new issues noted tonight:

  1. Using Chromium to upload to Google Drive (and other sites), I see that the file upload dialog or ‘Open Files’ doesn’t display an icon against ~/Documents in the folder and file list. An icon is displayed when using Firefox or Google Chrome to upload. Noted on both Ubuntu and Xubuntu 20.04. Something must have changed recently as I use Chromium to upload on a regular basis and haven’t noticed the missing icon before. (Also noted in a Kubuntu 20.04 live session).

  2. The file upload dialog in Xubuntu 20.04 displays GNOME icons rather than the icon theme I have selected in ‘Appearance’. Presumably the Chromium snap only has access to a limited number of icon sets and falls back to the default sets available to snaps.

@oSoMoN, let me know if you need a bug report for these issues.

1 Like

I’ve recently noticed that Chromium no longer can display emoji. All I get are square boxes and some black & white symbols. E.g. https://getemoji.com/ renders like this:

I’ve also noticed this in my journalctl:

saus. 03 12:14:00 blynas chromium_chromium.desktop[5143]: Fontconfig error: Cannot load default config file
saus. 03 12:14:05 blynas chromium_chromium.desktop[5143]: Fontconfig error: Cannot load default config file
saus. 03 12:14:09 blynas chromium_chromium.desktop[5143]: Fontconfig error: Cannot load default config file

Unfortunately I don’t remember if earlier versions of snap-ified chromium had this problem or not. I’m quite sure Chromium in 19.04 did not have this problem (because I was working on a site where I had to explicitly add a “font-face: emoji” to my CSS to get colorful emoji characters in Chromium, and my site is now broken).

Of course it might be an upstream regression. I’m not sure how to check.

1 Like

I’m getting color emoji with the Chromium Snap, but I’m on the beta channel.

You could snap refresh --beta chromium, but be warned that I think you’ll need to delete your profile if you want to go back to the stable channel. (If you use Chrome sync that might not be that bad…)

Other thoughts: Do you have the fonts-noto-color-emoji package installed? Does the same color emoji work for you in other apps, e.g. Firefox?

Indeed. There have been changes in how Widevine is bundled and detected in upstream chrome that affect chromium too. I recommend downloading the latest chrome deb and extracting the WidevineCdm directory that lives in opt/google/chrome into $SNAP/.local/lib/. That directory contains a manifest.json file and a _platform_specific folder under which libwidevinecdm.so lives.

1 Like

Hey Paul, please file a bug report for these issues, if you don’t mind.

I’m seeing the same in a clean eoan VM (the chromium snap version doesn’t matter, all channels exhibit the problem). Interestingly my work laptop with the chromium snap from the stable channel doesn’t exhibit the problem, emojis are rendered correctly.
In both cases I’m seeing several instances of this error message:

[ERROR:child_process_sandbox_support_impl_linux.cc(79)] FontService unique font name matching request did not receive a response.

but it’s probably unrelated, given that emojis are rendered correctly and coloured on my laptop.

Would you mind filing a bug to track the problem?

No problem, done. Bug reports are as 1858628 and 1858630.

Sure. I’ve filed LP #1858636.

It’s not LP #1794354 because I don’t have fonts-symbola installed. (I do have fonts-noto-color-emoji installed.)

Try

snap refresh gtk-common-themes --candidate

and then restart your browser, it got the correct cursor working for me, after @kenvandine applied the fix .

2 Likes

Chromium not having access to .dot folders under $HOME is an issue for me, as I am using shared, short lived mtls certificates under .pki/nssdb. Is there a way to use the global nssdb?

3 Likes

Thanks for pointing out the issue. I filed a bug to track it, with a suggested solution which I will discuss with the security team.

3 Likes

I was just forced yesterday by ubuntu to use snapped chromium, which lead to tonns of problems:

  1. system proxy I using for development (pac server) not used sometime
  2. system certificates not used
  3. home dir in file selection is not my $HOME

snap security features is terrible, if I would to isolate something I would to use virtual environment, or chroot. Please restore deb chromium. Current one is almost unusable for me.

problem with system proxy is the following:

If you have running chromium and restart proxy which configured as “automatic proxy” chromium loose the proxy configuration and restores it only after restart.