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).
I wanted to ask about native messaging (https://developer.chrome.com/extensions/nativeMessaging). It’s a terrible idea where you register programs on the host with the browser in a json file and the browser than starts them and you can communicate with them.
The KeePassXC browser integration is making use of that, and this obviously breaks with snaps, whether Chromium or Firefox. I imagine it would be possible to write like a native messaging bridge and have a native-messaging interface in the snaps to support this, but I’m uncertain if anyone has looked at that at all.
[quote=“oSoMoN, post:7, topic:11179”]
Why would you want to not install the snap version? Does it break an existing workflow for you?[/quote]
Maybe because :
⋅ snap wastes disk space,
⋅ confinement is more pain than gain in « simple » desktop usage,
⋅ forces user to otherwise organize his⋅her personal data to make them still available through snap app’,
⋅ theming issues might also break some workflow or habits.
Snap can be installed without confinement --classic but then losing their safety benefit which sounds like a misuse.
IMHO backporting this change to the 18.04 LTS would undermine trust, there is no way to gauge whether LTS users signed up for snaps … indeed I’d say they absolutely did not. 19.10 of course still belongs to Canonical/Ubuntu, but 18.04 does NOT, it now belongs to its users.
I’m using 19.10. After the upgrade to snap I get this error message when I open the https://extensions.gnome.org/ page
“Although GNOME Shell integration extension is running, native host connector is not detected. Refer documentation for instructions about installing connector.”
