electron,google-chrome: Ozone/Wayland is broken

[primeos]

Electron: Broken since 16.0.6 (or 16.0.5): e06082e

• Segfaults at startup (also tested via the not yet packaged version 17.0.0).
• Actionable: The packaging might need improvements for Ozone/Wayland support (s. Google Chrome changes - e.g. libglvnd, pciutils, and the changes for Vulkan).
• Relevant upstream issue for Electron 16: [Bug]: segfault on startup at gpu_init.cc under native Wayland electron/electron#32436

Google Chrome: Broken since M98(?).

• Software rendering still works (and hardware rendering might be fixable via flags or Nixpkgs packaging changes).
• TODO: Paste the logs (could be GPU driver dependent)

This issue lacks information but I decided to open it anyway to track those regressions. Any help would be welcome.

cc @Synthetica9 (#156352)
cc @travisbhartwell @manveru @prusnak (Electron maintainers)

[edrex]

With vscode and Obsidian, I'm not seeing a coredump, just a hang at startup. Same cause?

[NANASHI0X74]

I took the venture into experimental territory today with setting NIXOS_OZONE_WL and ran into this issue. Can I help? I guess each affected package must be updated to fix this, does anything need to be done for electron itself additionally? Also, would it make any sense to install slack via snap instead of the .deb package?

[prusnak]

Electron 17.3.1 with Wayland fix has been released (contains this fix electron/electron#33499) and nixpkgs has been updated in #166587

Can someone please check whether this update has fixed the issue?

[NANASHI0X74]

not sure if this is the bast way to do this, but I just updated from the current unstable to master with nix flake lock --override-input nixpkgs github:NixOS/nixpkgs/master --update-input nixpkgs (as unstable is apparenty currently blocked :/ )
The rebuild takes a while now 😅

[edrex]

@prusnak which apps use the nixpkgs electron17? VSCode is on 17 but it bundles electron (should really fix that). Obsidian should be on 17 but is currently on 16. Will probably bump it and test if someone doesn't first.

[prusnak]

which apps use the nixpkgs electron17?

Grep pkgs/top-level/all-packages.nix for electron_17:

• element-desktop
• micropad
• super-productivity

[NANASHI0X74]

not sure if this is the bast way to do this, but I just updated from the current unstable to master with nix flake lock --override-input nixpkgs github:NixOS/nixpkgs/master --update-input nixpkgs (as unstable is apparenty currently blocked :/ ) The rebuild takes a while now sweat_smile

can confirm this works with element-desktop and slack :D nice 👍

[ivankovnatsky]

For me slack still crashes (as it's not using electron17 yet i guess, not sure how it runs on your side), I see that that PR already landed in nixos-unstable https://nixpk.gs/pr-tracker.html?pr=166587, which I use.

element-desktop launches and runs fine.

[NANASHI0X74]

slack's actually a bit flaky I noticed, sometimes it works and sometimes it doesn't display anything (but seems to load the window title at least)
no idea what the problem is there

[wmertens]

FYI this is a known issue and the workaround is to run the affected program multiple times, eventually it will work. I do believe it's fixed in recent Electrons but I don't have pointers offhand.

[edrex]

Tested with obsidian 👍

I think this issue can be closed? It's honestly pretty nebulous as written (the chrome breakage was fixed months ago)

[edrex]

The only additional change would be to backport the fix to earlier electrons, but probably better to get those packages which depend on old electron upgraded.

[edrex]

VSCode 1.66 was released with electron 17.2.0. The insider (nightly) build has the needed 17.3.1, and indeed works under wayland (with some jank):

    vscode-insider = (prev.vscode.override {isInsiders = true;}).overrideAttrs (oldAttrs: rec {
      src = (builtins.fetchTarball {
        url = "https://update.code.visualstudio.com/latest/linux-x64/insider";
        sha256 = "048aizmk3513z1y6rxlfg87k7b74hilh6kydvgpz9lhrj1gymirf";
      });
      version = "latest";
    });

We will have to wait for the April stable release.

[wmertens]

I wonder if we can't patch the official release with our own electron?

[edrex]

@wmertens wayland isn't stable in the insider build. I think users should keep running under xwayland for now, and hopefully wayland support will be stabilized upstream before the 1.67 release.

[xaverdh]

ah never mind I think this is due to #164163..

[edrex]

Suggest we close this (@primeos) and open specific issues for each problem to get things in good shape (and we can still reference this one to act as an index).

The VSCode instability I mentioned is tracked upstream in microsoft/vscode#148507.

Obsidian is running very well for me native, however it needs a wrapper patch to use wayland by default or respect NIXOS_OZONE_WL=1. For now launch with obsidian --ozone-platform=wayland.

[primeos]

Feel free to split this issue up and(/or) close it. I don't use Electron apps or Google Chrome (anymore) and IIRC I only opened this issue to centralize the discussion and raise awareness. AFAIK our packaging is lacking and we'd need a general abstraction for Electron apps (there are just so many and they're currently packaged quite inconsistently). Ideally that abstraction could also be used for Google Chrome (where changes are usually required first - especially since we package the beta and dev channels as well).

[wmertens]

@primeos do you happen to have some ideas for such an abstraction?

I know many apps are just elf-patched versions of the distributed electron binaries, but I don't know enough about electron (yet). Do you think we could scrape the custom code out of those packages and pair it to our own build of (the correct version of) electron?

[primeos]

I was thinking of something like mkElectronDerivation (for the lack of a better name) that mainly provides the correct runtime dependencies and wrapper options by default (it might also require an attribute like majorElectronVersion in case there are breaking changes required to support newer Electron versions but ideally this could be avoided as it's probably annoying for packagers / update scripts). That way all Electron apps should behave the same (apart from the Electron version, etc.) and not miss any optional dependencies (e.g., for Wayland support).

Do you think we could scrape the custom code out of those packages and pair it to our own build of (the correct version of) electron?

That would be nice and IIRC it's supposed to be possible but I guess it would be the next step after having a basic abstraction. It could provide lots of advantages (security updates, bug fixes, etc.) but of course also drawbacks like incompatibilities.

[wmertens]

Ok, that makes sense. I'm sure there's lots of incompatibilities between major versions, or vscode wouldn't have waited so long to upgrade.

I'll have a look but most likely it won't be me that gets this done :)