Unable to launch on latest wl_roots due to Chromium bug

[akselaase]

Does this issue occur when all extensions are disabled?: Yes

• VS Code Version: visual-studio-code-bin 1.63.2-1 (899d46d)
• OS Version: Arch Linux per February 1st 2022 with sway 1:1.7-1 and wlroots 0.15.0-4

Also happens on 1.64.0-insider (7b9e5c3)

Steps to Reproduce:

1. Start VS Code with code --enable-features=UseOzonePlatform --ozone-platform=wayland --verbose
2. Observe output:

Warning: 'enable-features' is not in the list of known options, but still passed to Electron/Chromium.
Warning: 'ozone-platform' is not in the list of known options, but still passed to Electron/Chromium.
[2358162:0201/181136.563772:WARNING:wayland_drm.cc(68)] Failed to get drm magic
interface 'wl_output' has no event 4
tcmalloc: large alloc 1073741824 bytes == 0x1fe4e4cf4000 @  0x56537807d735 0x7fdda29e7047
/dev/fd/3: No such file or directory
Server response:
/dev/fd/3: No such file or directory
Server response:
/usr/bin/code --enable-features=UseOzonePlatform --ozone-platform=wayland    27.83s user 1.06s system 99% cpu 29.026 total

(last line printed by shell)

The issue is caused by this Chromium issue and is also reported to Electron and wlroots. The fix is backported to Electron 13 (electron/electron#32652).

This issue makes vscode unable to launch on Wayland. A workaround is running through XWayland, but that is blurry on hidpi-displays.

I can send a crash-dump on email if you wish.

[IllusionMH]

/assign deepak1556 -meganrogge

[ozls]

I have the exact same environment and observe the exact same issue. Very interested in a fix!

[heppu]

Any news or work arounds one might be able apply to get this working?

[elipp]

Still present in Arch Linux/sway-1.7/wlroots-0.15.0 + VSCode-1.64

[glanch]

On Arch you can use this workaround @heppu @elipp @ozls @akselaase

[elipp]

@glanch yeah, did that for a while... While it pains me, I opted to just enable xwayland in sway for the time being, since I don't have any HiDPI screens in use...

[SpencerSharkey]

bumping electron to the latest 13.x release with the backport'd fix got stuff working again...

but with vscode moving to electron v16 looks like we're now waiting for electron/electron#32603 to ship in a later release