Call for testing: chromium-browser deb to snap transition

you should file bugs about these two issues … if you dont tell the developers, they wont know and wont fix it :wink:

3 Likes

The snap is working. Bookmarks are there along with stored username and passwords.

What is NOT working is access to file partitions other than ~HOME, which completely breaks my workflow. Have had to resort to Firefox, which is fine, but I run both routinely.

I have control of my computer and, frankly, resent being “reigned” in. Better is to let me do what I want without restrictions.

Apparently there is a workaround to install the snap with a --classic switch. I have not tried it.

Thanks!

Did anyone get chromedriver working with the chromium snap? The project I’m working on has a test suite built with Robot Framework’s SeleniumLibrary, which worked fine on Ubuntu 19.04, but now it fails on startup with mysterious

WebDriverException: Message: unknown error: Chrome failed to start: exited abnormally
(unknown error: DevToolsActivePort file doesn’t exist)
(The process started from chrome location /snap/chromium/current/command-chromium.wrapper is no longer running, so ChromeDriver is assuming that Chrome has crashed.)

There are a bunch of messages in journalctl about

lapkr. 12 10:36:04 blynas audit[25465]: AVC apparmor=“DENIED” operation=“open” profile=“snap.chromium.chromedriver” name=“/proc/25465/mem” pid=25465 comm=“5c95b28f4a1b1d7” requested_mask=“r” denied_mask=“r” fsuid=1000 ouid=1000
lapkr. 12 10:36:04 blynas kernel: audit: type=1400 audit(1573547764.515:133): apparmor=“DENIED” operation=“open” profile=“snap.chromium.chromedriver” name=“/proc/25465/mem” pid=25465 comm=“5c95b28f4a1b1d7” requested_mask=“r” denied_mask=“r” fsuid=1000 ouid=1000

but I don’t know if that’s the cause of it or not. (Why does chromedriver want to access its own /proc/$pid/mem anyway?)

Please note this is not a workaround. The --classic option only allows you to install a snap that is already confined with classic confinement, it does not switch confinement from strict to classic. See https://snapcraft.io/docs/snap-confinement for more details.

2 Likes

Is there an easy way to access partitions with snaps?

Well, in that case the --help switch might be identical to the man page. In almost all cases those differ and the separate man page is more comprehensive than the help switch.

This lack of exposure to the GNU userland is the whole reason for my criticism. All those common GNU commands do not work anymore: man, info, whereis, whatis and probably a lot of others.

Every new app that is “snapped” will become a stranger to the underlying GNU-(user)land. That is a conceptual flaw which should be fixed with high priority.

re: man pages from snaps, the snapd team has started to look at how to expose man pages from snaps to the host system. I can’t say when this will be completed, but it is on our radar as an issue we intend to fix in the somewhat near term.

1 Like

The easiest way is probably to setup bind mounts from your other partitions to removable-media directories such as /media or /mnt.

2 Likes

Hi @oSoMoN

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.

5 Likes

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:

  1. snap updates, copies .config/chromium
  2. I keep using old version of snap which is using old .config/chromium
  3. 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).
  4. 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.)

GooPG uses native host messaging, which currently won’t work because of bug #1741074.

1 Like

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.

The most important bits are:

options.binary_location = "/snap/chromium/current/command-chromium.wrapper"
driver_path = "/snap/bin/chromium.chromedriver"

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.

Indeed the home interface disallows access to .dot files and folders immediately under $HOME/.

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.

I have described it in more details there.

It doesn’t look like my case:

% 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

So it looks like refresh-app-awareness is not working as intended for you.

May I suggest you comment to explain the problem on the snapcraft thread I linked to in my previous post?

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.