The chromium snap stores its profile in ~/snap/chromium/current/.config/chromium/.
Try moving that directory out of the way, or deleting it entirely (with the not running), and run chromium again. Does this import your full profile?
1 Like
I’m not sure about history, but passwords are usually kept in the system keyring (gnome-keyring-daemon), so you should be able to access them if you re-connect chromium to password-manager-service.
Yes, that’s the problems: it’s disconnected, and therefore can’t see your saved passwords. The fix is to connect, not disconnect.
Thank you both, @oSoMoN and @mgedmin! A combination of both of your hints helped resolve the issue for me:
- I connected chromium to the password-manager-service
- I removed snap’s chromium’s profile folder in
~/snap/chromium/current/.config/chromium/ - I copied my original chromium profile folder from
$HOME/.config/chromiumto~/snap/chromium/current/.config/chromium/, essentially replacing it - Additionally, I had to remove the extra
Execparameter--password-store=basicfrom my chromium.desktop file. I put that there yesterday as per another hint from this thread.
All of that together seemed to have done the trick, finally. I hope the old profile folder doesn’t mess up chromium in the long-run.
Merely removing snap’s chromium’s profile folder (instead of replacing/overwriting it as described above; otherwise having done all of the above) did not work for me, however. In this case, snap’s chromium would not import anything from the previously installed chromium version for me, not even profiles or bookmarks.
@oSoMoN: Thank you especially for mentioning the path ~/snap/chromium/current/.config/chromium/! I had searched in ~/snap/chromium/current/ before, but it didn’t occur to me to look for a hidden folder in there 
. I couldn’t find this documented anywhere – and due to this forum’s weird lazy-loading, I didn’t see yesterday that you had posted this in February already.
1 Like
It took me some time to grok this too. Basically, each snap’s ~/snap/NAME/{revision, current} directory is your home directory for that snap version, with the file layout exactly the same as the “real” home directory.
Yes, that way you can call
sudo snap disconnect <snapname>:home
for any application that you do not trust and want to prevent to access your personal data. the app still has a home dir to use but can not access anything in the actual $HOME to steal documents 
3 Likes
@oSoMoN In this week’s Desktop Team Updates - Monday 6th July 2020 - #3 by oSoMoN, you noted
When that rolls out, will it get connected for existing chromium installs?
I am trying to run chromium (snap version - it is all that is available) on an LXD container in Ubuntu 18.04, but not using X display :0. However it always fails.
$ DISPLAY=:10 openbox --startup chromium
mkdir: cannot create directory '/run/user/1000': Permission denied
X11 connection rejected because of wrong authentication.
[22215:22215:0706/113629.960979:ERROR:browser_main_loop.cc(1473)] Unable to open X display.
The directory /run/user/1000 already exists and contains snapd-session-agent.socket so I think that is not a problem.
All of these fail with the same error message:
$ DISPLAY=:10 chromium
$ chromium --display :10
$ chromium --display ':10'
$ chromium --display 10
These work fine:
DISPLAY=:10 openbox --startup xeyes
DISPLAY=:10 xeyes
and are displayed in a Xephyr instance as intended.
Firefox also succeeds.
This ALSO succeeds in displaying a window in the Xephyr instance:
$ DISPLAY=:10 openbox --startup chromium-browser
but it is just a dummy window, not a browser. I guess that is intentional.
it definitely is … no snap can write directly to /run/user/$uid typically XDG_RUNTIME_DIR points to a confined snap specific dir for security reasons:
$ snap run --shell chromium -c /usr/bin/env|grep XDG_RUNTIME_DIR
XDG_RUNTIME_DIR=/run/user/1000/snap.chromium
EDIT: here are some wrappers i used quite a while ago to build a kiosk based Ubuntu Core system using chromium:
https://github.com/ogra1/dashkiosk-client-browser/blob/master/xwayland-dashkiosk-launch
perhaps that gets you some ideas to work around the issue …
That’s a good question. According to the documentation, « Auto-connect indicates that the interface will be connected by default when the snap is first installed ». That seems to imply that the auto-connection won’t happen on update/refresh, only on first install.
No, when the snap is refreshed, assuming that chromium is granted auto-connection, the snap interface will get auto-connected upon normal refreshes. Snapd refreshes assertions just the same as snap blobs.
2 Likes
But thank you for pointing out that our docs are misleading in this way, I will try to get that updated and made more clear
1 Like
Running 20.04, I’m using the default Yaru cursor (although enlarged due to my 1080p screen). In Chromium only (I use the beta channel), I’ve noticed the waiting cursor — the spinning one — from the Adwaita cursor theme. It has usually been very brief, so hard to confirm, but I am getting it consistently while the video loads on this page: https://www.nytimes.com/video/world/100000007271927/pacific-island-rescue-video.html. Anyone else seeing this?
I’m seeing a couple of occurrences of cursor:wait in the CSS code of that page’s source. I wonder if that may be what triggers this unexpected cursor you’re seeing. Are you seeing it on any other webpages?
I do see it on other pages, they just don’t usually show the wait cursor very long, and usually on reload they don’t show it (since the content is in the cache?). I had been waiting to find a page that I could get it to show consistently, and that is the first one.
Whenever I see the wait cursor in Chromium, it always looks like the Adwaita cursor, not the Yaru wait cursor I see in other apps.
1 Like
I noticed the Adwaita theme for the “grab” cursor as well on the Accuweather/Mapbox radar map. Confirmed seeing Adwaita theme cursor for as least wait and grab using these demos: https://developer.mozilla.org/en-US/docs/Web/CSS/cursor
I installed Google’s Chrome deb, and it also shows the Adwaita theme cursors for those demo pages, so I guess it’s a Chromium bug, not with the snap packaging. I will file a bug with crbug when I get a chance.
I filed Issue 1114812.
Edit 2020-08-18: After more testing by me and others in that Chromium bug, it looks like this is specific to the Chromium snap, since we’ve been unable to reproduce with the Chrome deb. I’ve filed bug 1892085.
The latest (v87) build of chromium comes with Ozone Wayland built in, which you can enable with the -enable-features=UseOzonePlatform -ozone-platform=wayland command line flags. The app however fails to start:
~ chromium -enable-features=UseOzonePlatform -ozone-platform=wayland
/home/XXX/Music was removed, reassigning MUSIC to homedir
[40498:40498:0907/112057.812365:ERROR:wayland_connection.cc(73)] Failed to connect to Wayland display
[40498:40498:0907/112057.818035:FATAL:ozone_platform_wayland.cc(175)] Failed to initialize Wayland platform
fish: “chromium -enable-features=UseO…” terminated by signal SIGTRAP (Trace or breakpoint trap)
Is there anything that I can do my end? I’ve tried to enable the wayland plug, but no joy:
~ sudo snap connect chromium:wayland
error: snap "chromium" has no plug named "wayland"
3 Likes
Also, chromium does not seem to respect the chosen audio output or input in pulseaudio. It will latch to the last connected one, regardless of what you have selected on the output or input choosers.
1 Like
I upgraded my main machine from Focal to Groovy, and now the first launch after a reboot of the Chromium snap is taking much longer than before. The one time I timed it, it was over 30 seconds. Anyone else seeing this? I’ve noticed this first launch took longer than further launches, but it always seemed to be under 10 seconds.
I tried another computer I could erase, and on Groovy that computer took about a minute to launch the Chromium snap after rebooting. Then I clean installed Focal on the same machine, and the Chromium snap was just under 10 seconds to launch after a reboot.
I haven’t noticed it for any other snap, although I don’t use many that I ever saw much of a launch delay like Chromium. VS Code for one doesn’t seem slower, but I didn’t compare.
Edit: I filed bug 1900783.
1 Like