Call for testing: chromium-browser deb to snap transition

Outside of the crash I mentioned (after closing program & quick re-entry b/c of irc message), so far I’ve had no issues (with wait after logging in before starting chromium). Usually I login once a day only, though at least two nights I didn’t suspend the system.

Given Olivier’s original post, Silvio, I don’t think that Olivier will roll out the Chromium snap as default to releases prior to 19.10. I know, though, that Olivier is very keen to switch to the snap given the maintenance required for him to keep up the Deb updates on all supported Ubuntu releases. It’s a lot of very hard work because of all the different dependency versions that he has to get Chromium running on. Having said that, given what he said in his original post, I think Olivier should consider as blockers the kind of things Silvio mentioned. It is not currently rock-solid for users, so until snappy resolves these issues, the Chromium snap should not be rolled out as default for 19.04 and earlier (if Olivier stays true to his word in the original post), and I think perhaps a reverse of the rollout for 19.10 should be considered (for the sake of users like Silvio who like to have excellent interim releases as well as rock-solid LTS releases).

3 Likes

That’s right, there are still a number of issues that are considered blockers, and the deb packages won’t be replaced by the snap until they are addressed. Rest assured that when the transition happens in an LTS, it will have been thoroughly tested and deemed usable in the latest release first. That’s the very reason why this was started early in the 19.10 development cycle, and for this call for testing.

Thanks everyone who shared feedback so far, please keep it coming.

6 Likes

Thanks for taking the time to share your feedback Silvio, this is very much appreciated.
Answers to your points below. Note that when I link to a known bug, I’m not discarding the issue. It will eventually be addressed (and contributions are welcome!).

Terribly slow first startup of Chromium after logging in

Can you please quantify how slow? A simple stopwatch measurement would be useful, and if you can run the snap with snap run --trace-exec chromium then close the window and share the terminal output that would be even more useful.

File save/open dialogs do not use the proper theming

This is bug #1791307.

Funky home directory in the same dialogs

This is bug #1798450.

All my saved login-credentials are gone so I have had to go through a number of tedious password reset sessions

Can you check whether the password-manager-service interface is connected? (snap interfaces chromium | grep password)

Parts of recent state keeps getting lost between browser restarts. Sometimes it is simply browser history but I also lost recently created bookmarks on at least two occasions

This is most likely because an update happened under your feet. I concurr this is very annoying, and currently being actively worked on. Can you test the instructions at [WIP] Refresh App Awareness - snapd - snapcraft.io ? This works for me, and I’d be interested in hearing whether it does for you too.

9 processes called Chrome when I open 1 Chromium window

Chromium’s architecture relies on multiple sandboxed processes for security. This is not specific to the snap. How is that a problem? Is it the name (“chrome” VS “chromium”) that’s bothering you?

a load of file system mounts when Chromium is running

Do you mean snaps that are mounted under /snap/ ?
That’s not specific to chromium, but an implementation specificy of snapd.

Gnome shell extensions plugin no longer works because it does not detect chrome-gnome-shell

This is bug #1741074.

1 Like

I noticed that a new release is in the candidate channel so I decided to test this feature by forcing an update.

I opted in and with Chromium running I refreshed the snap to use the candidate channel and was met with

error: cannot refresh “chromium”: snap “chromium” has running apps (chromium)

Excellent. Patiently waiting for a real update. :slightly_smiling_face:

I’ve noted a minor issue on a full Ubuntu MATE installation. I installed Chromium from the transitional deb package.

On the Web Browser drop-down in “Preferred Applications” I see Firefox, Chrome and Chromium as expected. Setting the default browser works here but the application icon is missing. Icons are present for Firefox and Chrome.

Edit: same issue in a Xubuntu live session except that the “missing icon” icon is displayed.

Further edit: in a Kubuntu live session the application icon is displayed (in the Web Browser tab of Default Applications) but Chromium is still listed twice. :frowning_face:

Woke my system from suspend (last rebooted yesterday), box hasn’t been updated yet (67 packages waiting) with ~39 minutes from wake time before I loaded chromium. Chromium opened with offer to ‘restore’ my windows.

I do believe waiting (on waking from suspend) helps, and in this case as I suspended system after midnight so maybe I rushed to close programs & suspend system which led to failure to continue session… It did restore my tabs correctly though so no issue.

New issue detected. Every time I reboot, it automatically logs me out from https://discourse.ubuntu.com/ or launchpad.net. I have to re-login every time. Gmail stays logged-in though. Is this a known issue ?

I’m not aware of any reported issues but I regularly visit Launchpad, Discourse or the Ubuntu Forums and occasionally find that I am not automatically logged in as expected.

As this also affects Firefox and Google Chrome I’m not seeing this as an issue specific to the snap version of Chromium which I am currently using on Ubuntu and Ubuntu MATE 19.10.

Terribly slow first startup of Chromium after logging in

Can you please quantify how slow? A simple stopwatch measurement would be useful, and if you can run the snap with snap run --trace-exec chromium then close the window and share the terminal output that would be even more useful.

Slow as in somewhere in the range of 3-7 seconds. In my previous installation Chromium would show up on screen in less than a second. And it is not only after logging in but often also when reopening a Chromium window after having shut down all previous ones. Even my libreoffice-writer/calc (not the snappy ones) start up in a fraction of what Chromium takes now.

My Dell XPS13 laptop of about 5 years old has a modest i7-3537U CPU @ 2.00GHz but coupled with the SSD it still used to be fast enough for my daily work.

File save/open dialogs do not use the proper theming

This is [bug #1791307](link removed).

Please see blow…

Funky home directory in the same dialogs

This is [bug #1798450](link rmoved).

Please see below…

All my saved login-credentials are gone so I have had to go through a number of tedious password reset sessions

Can you check whether the password-manager-service interface is connected? (snap interfaces chromium | grep password)

Parts of recent state keeps getting lost between browser restarts. Sometimes it is simply browser history but I also lost recently created bookmarks on at least two occasions

This is most likely because an update happened under your feet. I concurr this is very annoying, and currently being actively worked on. Can you test the instructions at ? This works for me, and I’d be interested in hearing whether it does for you too.

Even if that would works I don’t want that. I want to do my own updates in my own time. Snaps should hold off all updates until I use the Software updater or something similar.

9 processes called Chrome when I open 1 Chromium window

Chromium’s architecture relies on multiple sandboxed processes for security. This is not specific to the snap. How is that a problem? Is it the name (“chrome” VS “chromium”) that’s bothering you?

Actually this is a mistake on my part, these processes where indeed there. The unexpected name has probably thrown me off.

a load of file system mounts when Chromium is running

Do you mean snaps that are mounted under /snap/ ?
That’s not specific to chromium, but an implementation specificy of snapd.

Yes, I know that but that does not make it less annoying. Just another way snaps are sticking out.

Gnome shell extensions plugin no longer works because it does not detect chrome-gnome-shell

This is [bug #1741074](link removed).

I understand some of the issues I have are more snap related than snap-Chromium related. But that does not make it any better for me. For a number of reasons I am obliged to keep up with the latest Ubuntu version and 19.10 is only weeks away. The assurance that this transition will not be back-ported to previous Ubuntu releases until major issues have been resolved does not help me at all. I need a Ubuntu 19.10 with a properly working Chromium.

In the meantime I have moved to Debian testing because of this. Luckily I have a separate / and /home partition and keeping /home worked like a charm. So far I have no issues with this setup, although I do miss some of the Ubuntu-niceness. To boot my Chromium browser once again opens in a flash.

BTW: I removed all links because I was not allowed to post this otherwise.

1 Like

Just wanted to share some feedback myself. I installed the Chromium snap under Ubuntu 19.10. Contrary to other reports, the application launch speed is normal for me. The first one took a second or two, but I assume that probably has to do with some snap-related initialization. The following launches were instant, though I am on an SSD.

The themeing is actually working well under X11, except for save dialogs and the fact that it is outdated (right click menu shows grey highlights rather than orange). It is close under Wayland as well, but unfortunately the titlebar is Adwaita rather than Yaru for some reason. Also under Wayland there are issues such as lack of font hinting, and for Firefox in particular, an incorrect cursor (white rather than black), so it seems all XWayland applications have some regressions there.

Other than the theme issues, the Chromium snap seems to be working as expected. Let me know if there is something else that I can test.

2 Likes

My dmesg gets flooded with
[114081.618847] audit: type=1400 audit(1568277508.541:17300): apparmor=“DENIED” operation=“open” profile=“snap.chromium.chromium” name="/home/baz/snap/chromium/849/.config/chromium/Default/QuotaManager-journal" pid=3281 comm=“ThreadPoolForeg” requested_mask=“w” denied_mask=“w” fsuid=1000 ouid=1000
[114086.472544] audit: type=1400 audit(1568277513.397:17354): apparmor=“DENIED” operation=“truncate” profile=“snap.chromium.chromium” name="/home/baz/snap/chromium/849/.config/chromium/Default/Favicons-journal" pid=3281 comm=“Chrome_HistoryT” requested_mask=“w” denied_mask=“w” fsuid=1000 ouid=1000
[114087.314067] audit: type=1400 audit(1568277514.237:17355): apparmor=“DENIED” operation=“open” profile=“snap.chromium.chromium” name="/home/baz/snap/chromium/849/.config/chromium/Default/Cookies-journal" pid=3749 comm=“ThreadPoolForeg” requested_mask=“wc” denied_mask=“wc” fsuid=1000 ouid=1000

I’m using the Chromium Snap Edge version 79.0.3921.0
It seems it was updated very recently, and I noticed that the ‘simple HTML view’ or reader view if you will, is now missing from the Omni Bar. This was a feature I often used and miss it. Why was it removed?

Mine does not take the Yaru theme.

Just to update this post for those that might be searching for a solution:

The manual setting of the Flag for the ‘Page Distiller’ feature, was reset to the default. So, once enabled, I had my “reader” view back. More on the ‘Page Distiller’ here.

2 Likes

If the issue is that they don’t want to use snaps, then yes, there’s no point. But if that refusal is motivated by real technical concerns, then we would like to hear about them.

As an extension developer, one thing that snap completely lacks is usable access to the Native Messaging API due to snap’s aggressive sandboxing, this breaks basically all binaries that depend on libraries chromium does not. Two examples are the native binaries for my own Pass Companion and BrowserPass, this has been a known issue for a long time and as far as I’m aware, the resolution for this scenario either has no fix or is poorly documented.

2 Likes

I have two ways to start Chromium.
Below is snap-Chromium. Starting from app grid, it takes a while to start and has not-very-pretty light colour bar on top.

The 2nd Chromium is the standalone one, shown below, taken off the snap and placed in my home folder and the executive file run with Gmrun. It starts almost immediately and correctly takes the system theme - Yaru-dark.

Now, I’d create a desktop file, so it can be placed permanently in the favourites. And the snap one taken off the app grid. For the moment, it runs off Gmrun.

All web browsers are standalone, so a snap is not needed for them. All you need is to make a desktop file to run the executive and a link to it. It might be easy to create a deb out of the standalone Chromium.

Note: Just ran that executive file from the Linux Mint (Eoan), and it correctly read the system theme there too. Mint doesn’t have snaps, only flatpaks.

Maybe, you’d consider creating a deb file, @oSoMoN ?
I even opened this same Chromium from Arch Linux.

The snap Chromium is 607.3 MB
The standalone Chromium is 237.2 MB
Something serious to think about.

EDIT: See, if you can install libcanberra-gtk3-module to snap-chromium >> /usr/lib/x86_64-linux-gnu/gtk-3.0/modules/ Maybe, it’d start as fast as the standalone one.

1 Like

Thanks for the report @paulw2u. I can confirm the problem in Xubuntu. It appears that exo-helper ships its own desktop file for chromium. I have yet to try and reproduce the problem for MATE and Kubuntu. Would you mind filing a bug to track the issue?

Bug filed: Chromium is incorrectly shown when setting the default web browser for some flavours

Previously, you could limit Chromium to only having access to the “Downloads” folder using firejail.

This no longer works:
https://askubuntu.com/questions/1178995/how-to-sandbox-chromium-thats-installed-via-snap

I’ve submitted a request for a alternative snap installation that achieves the same degree of sandboxing: