Plans for Chrome Flatpak stabilization (and request for testers!)

Hello! I currently maintain the Chrome Flatpak on Flathub beta, and I wanted to share some of the plans to move to stable, as well as request some consistent testing for future releases.

TLDR: I have had a lot of requests to move this to Flathub stable, and I’m looking to clean up everything and do this by the end of March. For some context on my concerns, the way Chrome works via Zypak is fundamentally a lot more hack-ish than Chromium, and thus has a higher risk of breaking on updates. (Yes, this applies to Electron apps too, but Chrome is undoubtedly more complex, and Electron releases will come after anyway, i.e. Chrome would break first). There are users using unstable Chrome releases that have reported Zypak bugs in the past (thanks @tinywrkb!), but I want something a bit more reliable to be in place here.

In addition, Zypak has two modes of operation, one for Flatpak 1.8+ if unprivileged user namespaces are enabled, and one for any other cases. However, the latter is rarely used at this point, and although it’s probably fine for Electron (it only ever forks the Zygote once or twice anyway), I’m a bit more hesitant here, because again, Chrome is the most likely one to break first.

To compound all this, there’s a decently high chance I’ll be switching to Chromium soon as my primary browser due to its arm64 support (feel free to guess why), so I won’t be putting Chrome through day-to-day testing like currently.

With all this in mind, I have two key points to my plan:

  • I want to keep the beta channel alive for Chrome beta/dev builds and would like some testers to volunteer to run this as a primary driver and report issues! This would allow to find any Zypak breakage before the Chrome stable release comes out, giving some decent buffer time in between. (This will likely be a separate app ID, so you could, say, install both beta/dev & stable, then sign into both with the same Google account so everything syncs over to stable, so you have a fallback in case of breakage.)
  • I will likely require Flatpak 1.8+ w/ unprivileged user namespaces for the stable channel (but not unstable!), unless I can get some testers to explicitly run this. This hasn’t seemed to be a super major issue for adoption so far for Chromium itself, and anyone on an older version could use the unstable channels (or I might add an override or similar w/ a more explicit warning). Again, this is simply much less tested, so you’re kind of subjecting yourself to a less stable experience anyway. The exception would be if I can have some people testing this more reliably to make sure it stays working! But again, I’m doubtful it’s going to be that much of a requirement, again given Chromium’s popularity here. (We require Flatpak 1.6+ anyway due to some device=all bugs.)

Meanwhile, I’m going to be spending some time looking into some reported issues with desktop icons (again! so much fun!) and removing the warning page on startup, i.e. generally trying to make it as polished as possible. There are some other areas I’m looking into as well (do we need to relax filesystem permissions, or are new portal versions widespread enough? etc).

(Note: I am aware I said I was originally planning on stabilizing by the end of the month on the Matrix, and I was going to post this earlier as well, but to be entirely frank, everything going on has sucked out a lot of motivation here, hence the month delay.)

TL;DR: I would very much like people willing to test beta/dev Chrome releases and report issues to trap Zypak bugs / required changes before they hit stable!! I’ll be prepping this part by the end of the week most likely, and then everyone can go wild.

8 Likes

arm64 Thinkpad? :slight_smile:

If it’s a separate app ID, you could consider putting it into non-beta Flathub? Other Major Platforms have the beta & canary Chromes (and analogous Firefoxes, Edges, and other obscurely-named browsers) in their main repo.

(Perhaps this is indeed what you intend.)

I think you could even consider a higher minimum version since the status quo is that Chrome is not available at all (ignoring beta). Maybe this would mean being able to rely on newer portal versions too?

I looked at Flathub Statistics and Flatpak 1.8+ covers the vast majority of systems.

(8–9k online Endless OS users are on Flatpak 1.8 or older; the remaining 20–21k are on 1.10 until we push a release with 1.12 in the next few months. But all these released versions pre-emptively hide any com.google.Chrome coming from Flathub from appearing in GNOME Software so they are not a reason to require anything older than 1.12.)

1 Like

Hmm, I was initially thinking flathub-beta also just because it would be higher risk for Zypak issues themselves (i.e. the chance of someone hitting an issue on our end is higher)…that being said I’m not particularly tied to that.

Thinking about this more, this would maybe make it safe to assume a portal version that we can drop filesystem=home on.

1.8 on its own would be fine too anyway, we’d have it working anywhere the Chromium Flatpak works.

1 Like

The icon issues you refer to, are you meaning getting the default Wayland icon on Plasma Wayland session?

@refi64 thanks for developing Zypak, it’s pretty amazing work!

I’ve been running Chrome as a Flatpak for a while now. Started by having to disable the sandbox, then moved to use the early Zypak versions, saw a mix of strange issues, until getting the current perfect state of Chrome + Zypak.
It’s pretty clear to me that a lot of time have been invested in development and debugging in order to get to the current state, which I’m not sure how many users appreciate.
So if no else says it, then let me just thank you here for your efforts.
Also, thanks for the mention.

I have had a lot of requests to move this to Flathub stable, and I’m looking to clean up everything and do this by the end of March.

I had a small hope that this will be accompanied by an official adoption by Google with all that comes with it. Binary distribution from Flathub’s repo, delta updates, inclusion of the sandboxing and other patches, aarch64 support, etc.
Have we given up on this? Can Flathub as an organization contact Google? Or maybe Fedora who’s invested in Silverblue or Red Hat has more pull?

I want to keep the beta channel alive for Chrome beta/dev builds and would like some testers to volunteer to run this as a primary driver and report issues!

I agree with @wjt. I think it would be better to a separate app IDs for the Beta and Dev channels, and publish them via the stable Flathub repo.
I suspect that web developers would appreciate having access to non-stable Chrome releases, and having them listed in the web store or the desktop app manager, and without having to add the flathub-beta repo.
This will get you guinea pigs without asking, and the fact that these are non-stable builds means that the user will be more tolerant for breakage, and willing to downgrade until a bug is fixed.

I switched to Edge a while back. Without vertical tabs (with collapsible pane), and having control on dark mode, Chrome feels dated, and it’s not that great on mobile.
So I’m not testing Chrome’s unstable builds these days, and Edge Dev is a bit lagging behind Chrome’s unstable builds.
Still, if there are not enough testers, then count me in.

3 Likes

Ah yes, fond memories of pouring over strace logs trying to figure out why everything would crash…

Thank you!

I can try throwing out a probe again, but it would almost definitely need some more pull. When I had last checked, upstream was basically “we’re not interested in a new sandbox”, and the easier distribution via Flatpaks isn’t as attractive since the frankendebian build infra Chrome uses is shared by other Google projects anyway.

This definitely seems to be the generally preferred direction that I’ll probably go in.

I guess I’ll see how it is in one or two weeks…though apparently even the Flatpak twitter highlighting this article only managed to result in Twitter replies saying that it should already be stable and asking for dotnet extension bugfixes (??), so I’m slightly less confident in how the tester pool might turn out :sweat_smile:

2 Likes

I add my thank to @refi64

I’m happy to test the dev version. Waiting for news here!

2 Likes

Chrome Dev is now up on Flathub! All testers are now free to, err, test :smile:

4 Likes

Chrome stable is now on Flathub!

1 Like

The stable version has been in flathub-beta for a while.
The stable is in the beta repository, while the dev version is in the stable repository… a bit confusing :slight_smile:

Now, both of them are on stable. Dev just came first because I wanted a consistent place for testing to be available first.