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
I upgraded my laptop from Focal to Groovy and now I canāt launch Chromium at all in a Wayland session:
[5379:5379:1023/110218.809226:ERROR:browser_main_loop.cc(1426)] Unable to open X display.
AFAIU this is a known issue with Mutter dropping support for the abstract X11 socket, while snaps rely on the abstract socket donāt actually set up a /tmp/.X11-unix/X0 socket in the sandbox.
For now Iām using socat to forward the abstract socket to the real socket as a workaround, but it is very slow:
socat abstract-listen:/tmp/.X11-unix/X0,reuseaddr,fork unix:/tmp/.X11-unix/X0
1 Like
Indeed, this is a known regression in mutter 3.38, which @jamesh fixed. The fix should make its way to a maintenance release and will be SRUed to groovy as soon as possible.
3 Likes
The fix for Mutter is now available in groovy-proposed, so is on the way to groovy-updates:
1 Like
This may be of interest to people monitoring this discussion.
6 Likes
I saw this on the Chromium blog: https://blog.chromium.org/2021/01/limiting-private-api-availability-in.html
It talks about āthird-party Chromium based browsersā, which I thought at first meant things like Brave or Vivaldi, but the Arch Chromium maintainer says it applies to them (https://lists.archlinux.org/pipermail/arch-dev-public/2021-January/030260.html).
I donāt use sync myself, but I would miss the Google Translate feature.
2 Likes
That isnāt my understanding from the press release. Theyāre talking about 3rd party Chromium-Based. Not Chromium as itās Chromium and not based on Chromium. I take it as your 1st meaning as in my opinion the nuance isnāt that subtle.
2 Likes
At this point this isnāt really clear. It is being discussed on the chromium-packagers group.
3 Likes
That would really suck if they do remove syncing.
1 Like