The chromium browser has been available as a deb package for all supported Ubuntu releases and as a snap since version 60, and the time has come to start transitioning away from the debs.
In a first step, the transition will be happening exclusively for Ubuntu 19.10 (Eoan Ermine) users, and once I’m confident it is rock-solid it will be rolled out to stable releases, starting with disco and then the LTSes.
How does that work? The deb packages have been updated in eoan to install the stable snap on upgrade or new install (credit for the original implementation goes to the LXC team). Special care has been taken to not break existing workflows and to make the transition seamless:
when running the snap for the first time, an existing chromium user profile in $HOME/.config/chromium will be imported (provided there is enough disk space)
the chromium-browser and chromedriver executables in /usr/bin/ are wrappers that call into the respective snap executables
chromedriver has been patched so that existing selenium scripts should keep working without modifications
if chromium was the default browser, the chromium-browser wrapper will take care of updating it to the chromium snap
similarly, existing pinned entries in desktop launchers will be updated to point to the snap version (implemented for GNOME Shell and Unity only for now, contributions welcome for other desktop environments)
the apport hook has been updated to include relevant information about the snap package and its dependencies
If you live on the edge and are running Ubuntu 19.10 already, I would appreciate your feedback on this transition. Please share it here, or file bugs with ubuntu-bug chromium-browser.
At some point all 18.04 Ubuntu Budgie users will be transitioned - UB ships chromium-browser deb as a default.
Guessing we will need to SRU the seed update to chromium-browser snap? Or would an SRU change from chromium-browser to firefox would be the preferred migration route?
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.
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’.
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.
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?
and drop the --ppapi-flash-path option when starting Chromium if ~/snap/chromium/current/.local/lib/libpepflashplayer.so 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).
