The issue you’re seeing with the app not launching is puzzling, and has not been reported anywhere else, as far as I know. Would you mind starting a new thread on the snapcraft forum to investigate that specific issue?
Regarding passwords, this is because the password-manager-service interface is not auto-connected. This is indeed bad user experience, and I am looking into options to solve this.
Please note that the candidate/from-source channel doesn’t exist anymore (the chromium snap is now always built from source), you should switch to the stable channel.
Comments about the passwords being lost when chromium has been broken:
when chromium is then loading again, the passwords are lost
so passwords are registered and saved again.
when chromium fails again (after some system packages upgrades (gcc/python/… ?), the newly saved passwords are again lost. That is strange as it seems passwords are saved outside the snap path. Not expected.
I was using ~/.chromium-browser.init to set force-device-scale-factor for chrome.
CHROMIUM_FLAGS="–force-device-scale-factor=2 --new-window"
How do I specify force-device-scale-factor for snap?
I am running xubuntu eaon and chromium snap doesn’t know about password I saved before with package (in gnome keyring).
This is a regression indeed. I’ve filed bug #1837746 to track it.
This is bug #1836616, which I just fixed. Until the fix reaches you, you can work around the problem by manually connecting the password-manager-service interface:
snap connect chromium:password-manager-service
This is probably caused by the lack of the --force-device-scale-factor=2 parameter. Does it go away if you run:
The cursor from 90s, I believe. It reminds of when I had to install Linux (Redhat in my case, pre-fedora days), and after it had booted I had to type in startx to start the x server which loaded the GUI, in my case was GNOME 1.x
I have always used basic password store instead of keyring in the desktop file. But this doesn’t work with snap. Can anyone tell me how can I keep doing that ?