Call for testing: chromium-browser deb to snap transition

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

For reference, this is being tracked by bug #1897454.

1 Like

Would you mind filing a bug with details to track and investigate this issue? Thanks!

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:

https://launchpad.net/ubuntu/+source/mutter/3.38.1-2ubuntu1

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

Sounds like Google considers Chromium shipped by anybody but Google, as a 3rd party project. I wonder what is really behind this move though?
But there are 3rd party browser sync projects that allow one to self-host, so maybe that’s an option for Chromium packagers to assimilate? Extra work for sure though.

2 Likes

Thank you, I was looking for it before I reported the problem.

@oSoMoN posted that Google client ID/secret has been removed from beta and dev builds (Desktop Team Updates - Monday 1st February 2021). I’m using the beta, so if it is live now I can confirm the Google Translate feature is still working. The original Google post linked to a list of APIs that included a bunch of things, including Translate, but later discussion on the mailing list clarified it was only sign-in/sync features that were being cut off, but they never gave an exact list that I saw.

1 Like

Is it hard to use Firefox sync/account functions for Chromium?

I don’t think that exists right now. Someone would need to write the code.

1 Like