Call for testing: chromium-browser deb to snap transition

I suppose you would need to add “snap:chromium” to the desktop seed, to ensure the snap is on the image. The “chromium-browser” entry doesn’t need to go away, the transitional package is not going away anytime soon.

I will make sure to announce the transition in bionic in advance so that you’re not caught off guard.

If you have specific concerns about snaps (or this snap in particular), please raise them on the snapcraft forum, and make sure to elaborate.


Wasn’t too impressed that I had to muck about with updates today because of this. No option to NOT upgrade chromium to this snap version and uninstall it.

@oSoMoN - it would be pointless anyone raising issues on the snapcraft forum if the issue is someone doesn’t want to use them, that would be like going to a cathedral to complain about religion …


No indeed, the transition from deb to snap is not being debated, it’s a firm plan that will eventually save a lot of engineering, builder and maintenance resources by removing the need to build every new version of chromium on all supported Ubuntu releases.

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.

Why would you want to not install the snap version? Does it break an existing workflow for you?
Note that by not upgrading to the snap, you’ll keep using an old, unsupported version with known security issues.


I tried uploading some bird pics to mewe before, but it doesn’t behave as expected with regards opening files.

These directories are not from my $HOME directory; and selecting different locations (eg. my pe2900 or de2900 servers where I wanted to go) didn’t change my folder view. I could work around it, but it wasn’t ‘nice’.

(Lubuntu 19.10)

ps: let me know if you want me to file bug report, or need more info/want me to test it again. I first tried drag-drop of my photo [from pcmanfm-qt] which didn’t work either, so was trying to upload via filename

Also note: I had updated well before I saw this, so my issue may be in the point “if chromium was the default browser, the chromium-browser wrapper will take care of updating it to the chromium snap” as firefox is my default browser


It appears image builders cannot reach the snap store because of restricted network access, bug #1832656 is tracking the problem. So I guess seeds will need to be updated to include the snap instead of the deb.

Do all the XDG folder shortcuts on the left result in an incorrect file view on the right, or only some of them?
I tested this on stock Ubuntu and the file dialog behaves as expected, and so does dragging and dropping files from nautilus.
A bug report would be welcome, please file it by running ubuntu-bug chromium-browser. Thanks!

re: xdg folder shortcuts - only some of them. eg. clicking Home near the top opens /home/guiverc/snap/chromium/733/ (with only the 733 visible). The folders below my $HOME were as expected (ie. documents, pictures etc). Bug-report will be filed next.

I upgraded/migrated/transitioned yesterday using the -snap1 version of of the Chromium deb. I rebooted my laptop and Chromium started with all bookmarks and saved passwords copied over from the old profile. It’s good to see that the mouse pointer issue has been resolved since the last time I used the snap version of Chromium some time ago.

Uploads, downloads, audio, video all seem fine. I don’t have a printer so I can’t test printing although ‘Print to PDF’ and ‘Save to Google Drive’ work as expected.

Apart from bug 1741074, the only issue that I’ve come across so far is when navigating to a folder outside of $HOME in order to upload a file I see a permission denied error on several directories, /boot for example. As I can access these directories with Firefox and Chrome is this something that needs to be fixed or is it a consequence of using a snap?

This is indeed a feature of the snap confinement, it won’t let the application see files on the host system (save for a few exceptions, like $HOME). I’m aware this is mildly annoying when wanting to attach e.g. log files to a bug report. Not much can be done about it, though.

Thanks for the feedback, by the way!


Does not use the system theme (in my case Yaru) in either Xorg nor on Wayland.

oh dear. I was worrying about that on behalf of Ubuntu 18.04 Budgie users.

Since the browser is so fundamental to the desktop - having a non-themed browser really breaks the aesthetics of the distro :frowning:

It should use the system theme (provided it’s in gtk-common-themes, which is the case for Yaru), and it does here. Is this on 19.10? What is your desktop environment?

I’m a bit bothered about the poor support for Flash Player.

An idea: How about confining e.g. these paths:


and drop the --ppapi-flash-path option when starting Chromium if ~/snap/chromium/current/.local/lib/ doesn’t exist? (Please note that passing an empty value, i.e. --ppapi-flash-path=, breaks Chromium’s built-in ability to load the plugin from one of the ‘normal’ places.)

Is this something you already have considered and turned down, or would it be possible? I think it would be an improvement, and Flash would keep being as easy to enable during the rest of its (short) remaining life as explained at this page.

I haven’t really considered it, mostly because of the upcoming EOL of Flash. These paths could possibly be added to the browser-support interface, this would require input from the security team. @jdstrand, how does that sound?

I use the yaru theme and I don’t use “system title bar and border” in Chromium as it takes vertical space. In this case you get a grey “title bar” as in picture from mohan-ram.
This looks a little bit strange as the top bar is dark by default.
In case you set theme in Chromium to Classic, the “title bar” will be almost white and if set to GTK+ a little bit gray.
I have changed the theme in Chromium to “Modern Flat”, that looks quite OK.

19.10 no modification at all. Stock, and when I toggle on Use System Title Bar option it freeze, I have to hard reset my machine. Mind you Brave browser and LibreOffice both look fine. Though LibreOffice reversts to using Human mouse theme (white) and not Yaru mouse theme (black).

I wanted to ask about native messaging ( 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.

1 Like

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

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