This is the current user agent string of the snap:
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) snap Chromium/78.0.3904.97 Chrome/78.0.3904.97 Safari/537.36
This is the user agent string for the deb package:
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/78.0.3904.97 Chrome/78.0.3904.97 Safari/537.36
I can confirm that web.whatsapp.com works if I change snap to Ubuntu in the user agent.
Is it possible to reconsider having a separate browser string for the snap? Given that a website as popular as web.whatsapp.com doesn’t work, it probably won’t be the only one. I’ve had to contact so many websites because they incorrectly blocked Linux and Chromebooks, I’d hate to have to do this again for the snap now.
Moreover, having a distinction between the snap and deb user agent increases the browser fingerprint, making it easier for websites to track us without our permission.
Given that the Chromium snap is strictly confined, chromium is in fact running in Ubuntu as far as Chromium is concerned.
Ubuntu used to include the version number in the UA, but this hasn’t been the case for a while now. I suspect that was removed for similar reasons.
I have set snap set core experimental.refresh-app-awareness=true but I keep losing some data when snap updates.
I usually never restart chromium (30 days uptime on my laptor currently). And here what I think is happening:
snap updates, copies .config/chromium
I keep using old version of snap which is using old .config/chromium
After couple of hours I open some url from another app (executes chromium https://...), running version of chromium crashes (maybe because newly executed chromium points to another .config/chromium).
New version of snap executes, but missing a data from those couple of hours. And I can confirm this data in .config/chromium of old version of snap.
This will probably affect few people but I pretty much immediately discovered that the snapped Chromium could not access files in hidden directories. (I extensively use .local/opt, .local/src, .local/include, etc. – so I guess it was bound to happen sooner than for most people.)
Chromedriver is working here with the snap. You can have a look at the snap’s own basic tests, which are installed in /snap/chromium/current/tests/, for example the chromium-version test.
I haven’t had a chance to test this with more complex setups though. If this doesn’t work for you, please file a bug with details about your setup. Thanks!
This is very unfortunate. It’s 2019 and companies still produce web pages that enable/disable features based on UA sniffing. I’d suggest using an extension (e.g. User-Agent Switcher for Chrome) to work around the problem.
The “snap” token was added to the UA string initially to allow snapcraft.io/store to identify unambiguously a system that knows how to handle snap:// links, to provide accurate installation instructions. This isn’t ideal, but it’s not something we can easily revert either.
Indeed. An extension to override the default UA string sounds like a good mitigation for privacy concerns.
That’s not quite correct. The app is running on whatever the host system is, but it has a very limited view of that system. The fact that the snap was built on Ubuntu is an implementation detail, even more so in the case of chromium which embeds and builds many of its dependencies at build time.
With experimental.refresh-app-awareness=true the snap won’t be updated while it’s running.
I am however seeing something that might explain your issue. I also have experimental.refresh-app-awareness set to true, and I have chromium running pretty much all the time, so it doesn’t leave it a chance to update. When I reboot my machine, however, is when the snap gets updated if a new revision is available. The application won’t launch until the snap is updated, however copying the data in ~/snap/chromium/ from one revision to the next might not be complete by the time the app is started (the browser is usually the first app I launch, and the profile directory can grow quite large), so the browser will start with an incomplete profile. This is definitely an issue with snapd.
% ls -la ~/snap/chromium/current lrwxrwxrwx 1 baz baz 3 Nov 22 13:11 /home/baz/snap/chromium/current -> 949
“currect” link was relinked at 13:11, while I was using old version of snap until 15:32:
% ls -la ~/snap/chromium/937/.config/chromium/Default/Login\ Data -rw------- 1 baz baz 589824 Nov 22 15:32 '/home/baz/snap/chromium/937/.config/chromium/Default/Login Data'
And just in case: % sudo snap get core experimental.refresh-app-awareness true
Cool. I still don’t know if it’s how the container apps behave or something else. But I’m expecting a way for root and other places.
Till very recently, it was Pop!_OS theme available from their own PPA. But now it’s the Ubuntu bionic default theme: Ambiance. I guess there should be a way for this apps to copy system defaults or ask the user if one prefer override it or use what is already set.
Good to know, thanks.
Sure!
It’s not quite true. You are just relying on the command line but: $ du -hs /snap/chromium/958 574M /snap/chromium/958
And $ snap info chromium | grep installed installed: 78.0.3904.108 (958) 160MB -
Please notify me if I’m wrong. I’m just looking at the numbers.
I may doodled it around. But as I told not important. For what reason should I adjust 60GiB and not using it!
Also there is more!
I don’t know how should I report this bug. When I click on Home shortcut on the left side of “Select file” window, this happens. I guess it’s pretty straight forward and no need any comments.
/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
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.
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.
My feedback after using snap Chromium for ~6 weeks (Kubuntu 19.10):
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.
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
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).
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.
Neat. I almost forget I am using a snap.