Closed JulianFP closed 10 months ago
Same here - arch, intel cpu, amd gpu, hyprland.
I get this error output in my terminal (Edit: doesn't seem to be related to the issue):
[35748:0815/214746.638720:ERROR:gl_surface_presentation_helper.cc(260)] GetVSyncParametersIfAvailable() failed for 1 times!
[35748:0815/214747.778123:ERROR:gl_surface_presentation_helper.cc(260)] GetVSyncParametersIfAvailable() failed for 2 times!
[35748:0815/214747.791778:ERROR:gl_surface_presentation_helper.cc(260)] GetVSyncParametersIfAvailable() failed for 3 times!
I only get this message once with v4.3.0, seems like it might be a wayland issue with the recent release.
I only get this message once with v4.3.0, seems like it might be a wayland issue with the recent release.
I am not sure if this error message is related. I get the message three times on both v4.3.0 and v4.4.0. Also as mentioned above, I have the same problem under i3 as well, which means that this issue is not exclusive to Wayland. However, under i3 I don't get this error message in the terminal.
You're right.
Looks like it's an electron26 issue - 4.4.0 bumped to 26 from 25.
If you edit /usr/bin/webcord
to use electron25 it seems to work.
Edit: I have the latest electron 26.0.0-beta.12 installed and 25.3.2
Running webcord --verbose
results in this vague error: Renderer process crashed - see https://www.electronjs.org/docs/tutorial/application-debugging for potential debugging information.
Edit 2: Running ELECTRON_LOG_FILE=/tmp/electron ELECTRON_ENABLE_LOGGING=true webcord
gives some audio warnings, might be Pipewire related.
[109376:0815/231152.936120:WARNING:sync_reader.cc(195)] SyncReader::Read timed out, audio glitch count=10
[109376:0815/231153.047165:WARNING:sync_reader.cc(195)] SyncReader::Read timed out, audio glitch count=20
[109376:0815/231153.158451:WARNING:sync_reader.cc(195)] SyncReader::Read timed out, audio glitch count=30
[109376:0815/231153.269419:WARNING:sync_reader.cc(195)] SyncReader::Read timed out, audio glitch count=40
[109376:0815/231153.380211:WARNING:sync_reader.cc(195)] SyncReader::Read timed out, audio glitch count=50
[109376:0815/231153.491243:WARNING:sync_reader.cc(195)] SyncReader::Read timed out, audio glitch count=60
[109376:0815/231153.602693:WARNING:sync_reader.cc(195)] SyncReader::Read timed out, audio glitch count=70
[109376:0815/231153.713831:WARNING:sync_reader.cc(195)] SyncReader::Read timed out, audio glitch count=80
[109376:0815/231153.806790:WARNING:sync_reader.cc(175)] ASR: No room in socket buffer.: Broken pipe (32)
[109376:0815/231153.806837:WARNING:sync_reader.cc(195)] SyncReader::Read timed out, audio glitch count=90
Electron 26 is in beta and has had changes with pipewire.
Running
webcord --verbose
results in this vague error:Renderer process crashed - see https://www.electronjs.org/docs/tutorial/application-debugging for potential debugging information.
Edit 2: Running
ELECTRON_LOG_FILE=/tmp/electron ELECTRON_ENABLE_LOGGING=true webcord
gives some audio warnings, might be Pipewire related.
I can confirm, I get the exact same error messages. I use Pipewire as well.
Looks like it's an electron26 issue
I can confirm this as well. Using Electron 25.3.2 completely resolves the problem for me. I also compiled discord_arch_electron from AUR (basically plain Discord except that it uses Electron provided by the system) with Electron 26 and I got the exact same behavior: The window goes blank after a few seconds. Discord however reloads the Window automatically, but the app is still unusable. I think this confirms that this is an upstream issue of some kind and not limited to Webcord. We should probably stick to Electron 25 until this is resolved.
EDIT: This is an upstream issue of Electron 26.
Please link the issue. I tested AUR package before publishing and not faced any issues.
If you edit
/usr/bin/webcord
to use electron25 it seems to work.
Better edit PKGBUILD
instead. Electron version can be changed in the first line, it also will set right dependency.
I can confirm that isse on arch (aur package), fedora (official rpm release) and unofficial flatpak. no matter wayland/xwayland/Xorg
Well, it should be fine to step back to Electron 25 for AUR package, I guess.
On Linux the only issue we care is #442, afaik. But actually the fix also was backported to 25.3.0, so Electron 26 is not necessary.
I still don't reproduce this issue on NVIDIA drivers and X11, maybe it's MESA only or hardware-specific? What about GPU optimizations? Does changing that do anything?
Also what about #444 and proposed workaround here? Maybe that's duplicate issue?
I still don't reproduce this issue on NVIDIA drivers and X11, maybe it's MESA only or hardware-specific? What about GPU optimizations? Does changing that do anything?
I am also unable to reproduce it using MESA/AMDGPU. Regardless of optimization setting. I see no difference between 25 and 26. So the issue is quite setup-specific for sure.
i've tried no sandbox, disable-gpu, disable-webgl, disable-3d-apis none of it worked fwiw, Electron 27.0.0-nightly with 4.4 works ok
fwiw, Electron 27.0.0-nightly with 4.4 works ok
Didn't even know that was being worked on considering 26 is still in beta. 27 alpha1 was just published like 5 minutes ago :joy:
Edit: Looks like electron 26 was released 2 days ago but the arch AUR package isn't updated yet, let me test that.
Edit 2: v26.0.0 doesn't fix the issue
I also have this issue after updating yesterday. I am running on hyprland with intel igpu. On arch linux
Can confirm as well, it starts without an issue, then the window turns blank after a few seconds.
I tried all the flags that usually solve similar issues: --enable-features=WaylandWindowDecorations,UseOzonePlatform --ozone-platform=wayland --force-device-scale-factor=1 --in-process-gpu
and nothing works. Same behavior.
Wayland (Hyprland) on Nvidia drivers.
Rolling back to WebCord 4.3.0 does the job for now!
Also what about #444 and proposed workaround here? Maybe that's duplicate issue?
That was the first thing I did when I encountered this issue but it doesn't help, unfortunately.
I still don't reproduce this issue on NVIDIA drivers and X11, maybe it's MESA only or hardware-specific? What about GPU optimizations? Does changing that do anything?
If you (or any other NVIDIA GPU owners) can test in Wayland, that would help narrow down the potential cause.
The grey screen issue definitely stems from the interaction between Electron and (recent) Mesa drivers (at least for RDNA 2 owners).
I believe I'm seeing the same thing on nvidia v4.4.0, but not v4.3.0 (unlike #444).
Setup: nvidia GPU, nvidia drivers 535 Kubuntu KDE, Wayland Using both .deb and .AppImage
Tinkering with the flags too much (enabling Wayland, at the least) also causes it to seg-fault on startup, which is probably worthy of its own issue (which I can file when I have more time later).
I also appear to have the same issue, and it's fixed by downgrading to 4.3.0.
Flatpak Nvidia GPU, Nvidia drivers 535 on host OpenSuse Tumbleweed Cinnamon on X11
Then this issue doesn't seem to be related to #444 .
How to Downgrade Flatpak Package for Webcord to v4.3.0 in Linux:
sudo flatpak update --commit=a35defd55a5da112609c61babd223c9f05aa198b1338cdbee0f72974e467765c io.github.spacingbat3.webcord
Source: https://itsfoss.com/downgrade-flatpak-packages/
Oddly, the grey screen issue on AMD/Mesa is nonexistent on Electron 27 Alpha, but persists on 26
it's not about amdgpu/mesa/webcord4.4 it exists on ryzen 5xxx with igpu and ryzen 5 with nvidia 3060 doesn't exist on haswell + igpu and haswell + amd polaris (rx580) problem is exclusively for electron26 discord and caprine are affected too
This issue doesn't bother the snap though. It works fine.
i have this issue too as an arch user
Discord however reloads the Window automatically, but the app is still unusable.
This made me to think it's renderer process constantly crashing for some reason. I guess it is good idea to implement renderer crashes handling for Discord window right now, eventually maybe for other/all WebContents
instances as well. I might also try do some fallback behavior, e.g. if it constantly crashes WebCord will restart and try to run with hardware acceleration forcefully disabled and GPU optimizations entirely ignored (this should last only for the current WebCord session).
Discord however reloads the Window automatically, but the app is still unusable.
This made me to think it's renderer process constantly crashing for some reason. I guess it is good idea to implement renderer crashes handling for Discord window right now, eventually maybe for other/all
WebContents
instances as well. I might also try do some fallback behavior, e.g. if it constantly crashes WebCord will restart and try to run with hardware acceleration forcefully disabled and GPU optimizations entirely ignored (this should last only for the current WebCord session).
Is this really a webcord issue? The snap package is also at 4.4.0
which is used by many now. And none haven't reported anything including myself.
https://github.com/electron/electron/issues/39515 Looks pretty close
What's about Electron 26.1.0
? Can anyone check it out?
On electron 26.1.0 issue still persist
https://github.com/SpacingBat3/WebCord/commit/eb034557fe63b4e3f3c4a1dbea6c0e4dfd8b1a65 might help with logging the reason of renderer crash (if it is renderer crash) or even workaround the bug if it is caused by hardware acceleration (there's new --safe-mode
flag that disables hardware acceleration and should disable most of Chromium command-line tweaks made by WebCord itself). Could anyone test the nightly builds from it?
I hope I did it right:
WebCord]$ LANG=C electron26 . --safe-mode
[WebSocket] Listening at port 6463.
[UPDATE] Application is up-to-date!
[WC_5:139] crashed
[WC_5:139] crashed
[WC_5:139] crashed
[WC_5:139] crashed
[WC_5:139] crashed
[WC_5:139] crashed
[WC_5:139] crashed
[WC_5:139] crashed
[WC_5:139] crashed
[WC_5:139] crashed
[WC_5:139] crashed
Crash count exceeded (>10), relaunching in safe mode...
[WC_5:139] crashed
Crash count exceeded (>10), relaunching in safe mode...
[WC_5:139] crashed
Crash count exceeded (>10), relaunching in safe mode...
[WC_5:139] crashed
Crash count exceeded (>10), relaunching in safe mode...
[WC_5:139] crashed
Crash count exceeded (>10), relaunching in safe mode...
[WC_5:139] crashed
Crash count exceeded (>10), relaunching in safe mode...```
every time window goes to black (or rather grey for me) webcord is restarted and `[WC_5:139] crashed` appears
I'm getting a different output from eb03455
:
npm start
> webcord@4.4.0 start
> tsc && electron .
[WebSocket] Listening at port 6464.
[UPDATE] Application is up-to-date!
[94542:0829/141939.717146:ERROR:gl_surface_presentation_helper.cc(260)] GetVSyncParametersIfAvailable() failed for 1 times!
[WC_5:139] crashed
[94542:0829/141946.273366:ERROR:gl_surface_presentation_helper.cc(260)] GetVSyncParametersIfAvailable() failed for 2 times!
[94542:0829/141947.843422:ERROR:gl_surface_presentation_helper.cc(260)] GetVSyncParametersIfAvailable() failed for 3 times!
[WC_5:139] crashed
[WC_5:139] crashed
[WC_5:139] crashed
...
In my case it seems to go gray and back to normal repeatedly. It feels related to the window getting focused but It's really hit or miss...
I upgraded my CPU from an AMD Zen+ CPU to a Zen3 and I immediately had this issue
[50:0829/212203.211805:ERROR:bus.cc(399)] Failed to connect to the bus: Failed to connect to socket /run/dbus/system_bus_socket: No such file or directory
Gtk-Message: 21:22:03.366: Failed to load module "canberra-gtk-module"
Gtk-Message: 21:22:03.366: Failed to load module "canberra-gtk-module"
[88:0829/212203.383454:ERROR:gl_factory.cc(120)] Requested GL implementation (gl=none,angle=none) not found in allowed implementations: [(gl=egl-angle,angle=default),(gl=egl-gles2,angle=none)].
[88:0829/212203.384539:ERROR:viz_main_impl.cc(186)] Exiting GPU process due to errors during initialization
[WebSocket] Listening at port 6463.
[122:0829/212203.451617:ERROR:gl_factory.cc(120)] Requested GL implementation (gl=none,angle=none) not found in allowed implementations: [(gl=egl-angle,angle=default),(gl=egl-gles2,angle=none)].
[122:0829/212203.452743:ERROR:viz_main_impl.cc(186)] Exiting GPU process due to errors during initialization
[135:0829/212203.461306:ERROR:gl_factory.cc(120)] Requested GL implementation (gl=none,angle=none) not found in allowed implementations: [(gl=egl-angle,angle=default),(gl=egl-gles2,angle=none)].
[135:0829/212203.462141:ERROR:viz_main_impl.cc(186)] Exiting GPU process due to errors during initialization
[UPDATE] Application is up-to-date!
Then it just shows a grey screen with nothing rendered
I have an even more bizarre situation that I thought I might add here.
As I said... Bizarre - but there are a couple of differing factors there (different desktop env and graphics cards on both).
P.S. The 4.3.0 downgrade on the PC / nvidia machine works great.
I have an even more bizarre situation that I thought I might add here.
- 2 systems
- Both Arch Linux
- Both systems using the latest flatpak version of WebCord (4.4.0)
- Laptop with Intel graphics running KDE
- Desktop PC with a Nvidia card running gnome-shell
- WebCord runs perfectly on the laptop, grey blank screen after a few seconds on the desktop PC
As I said... Bizarre - but there are a couple of differing factors there (different desktop env and graphics cards on both).
P.S. The 4.3.0 downgrade on the PC / nvidia machine works great.
That's interesting, I'm on a Fedora laptop running GNOME with Intel chip and graphics but using the RPM package.
The workaround I found is downgrading to the latest working commit on Flatpak
sudo flatpak update io.github.spacingbat3.webcord --commit=3456e73fb5e39dbf058a101d27467414f51baa9150dad89510d4c5a6da5985b4
You can also mask it so it doesn't update
flatpak mask io.github.spacingbat3.webcord
Make sure that you remove the mask after it works again
flatpak mask --remove io.github.spacingbat3.webcord
Ok, so downgrading to 25.x.y
is not an option for Windows users and most likely for macOS users as well, since even the latest version of Electron 25 still has the same issue with running on Windows or WineHQ. I guess I would have to downgrade to 24.x.y
which was the last known version without any critical bugs for everyone, although I don't really like the idea of downgrading to very old version of Electron that might be deprecated as soon as the next release is going to be made. 😕
I think I'll stay at Electron 26 for now. I still know the issue is quite specific to each setup and it's not really reproducible to everyone. In fact it seems Electron devs by themselves have hard time to reproduce this and without them trying to fix it or Chromium devs patching it on their own side if possible, I highly doubt any version of Electron 26 will have this fixed either.
Supposedly Electron 27 fixes it well enough to be usable again, so that might be what's needed:
https://github.com/ArmCord/ArmCord/issues/454#issuecomment-1701430082
Happy to test any flatpak builds with Electron 27 to confirm since I also see the issue
I also wonder about enforcing WebCord's software acceleration via --use-gl=angle --use-angle=swiftshader
and/or MESA env vars (to use llvmpipe driver). Maybe that could somewhat be more stable or at least be a way to reproduce this on any hardware?
Also what about --gpu-info
report?
I'd like to find some reliable way to make sure WebCord with safe mode executes in similar way on any hardware or user setup, even if it makes it to run horribly slow. The goal is to make sure there's a way for WebCord to automatically apply workarounds if renderer constantly crashes and given there was already reports of that happening with older Electron versions, adding such mechanism would be a good way to get rid of these issues for the future.
Also what about
--gpu-info
report?I'd like to find some reliable way to make sure WebCord with safe mode executes in similar way on any hardware or user setup, even if it makes it to run horribly slow. The goal is to make sure there's a way for WebCord to automatically apply workarounds if renderer constantly crashes and given there was already reports of that happening with older Electron versions, adding such mechanism would be a good way to get rid of these issues for the future.
GPU information object:
{
auxAttributes: {
amdSwitchable: false,
canSupportThreadedTextureMailbox: false,
glImplementationParts: '(gl=none,angle=none)',
glResetNotificationStrategy: 0,
inProcessGpu: true,
initializationTime: 0,
isAsan: false,
isClangCoverage: false,
jpegDecodeAcceleratorSupported: false,
optimus: false,
passthroughCmdDecoder: false,
sandboxed: false,
subpixelFontRendering: true,
targetCpuBits: 64,
visibilityCallbackCallCount: 0
},
gpuDevice: [
{
active: true,
cudaComputeCapabilityMajor: 0,
deviceId: 5761,
gpuPreference: 0,
vendorId: 4098
}
]
}
I get this issue on NixOS on an x86_64 laptop but not on NixOS on my M1 Pro. Both are using the most recent Flatpak builds.
I had to rollback to 4.3 too
electron/electron#39515 Looks pretty close
There's actually a lot of tickets in electron/electron
describing renderer crashes by now:
Both of these issues suggest that this bug might still be reproducible in Electron 27. Additionally, electron/electron#37531 suggest that --disable-sandbox
and --disable-gpu-sandbox
switches might make Electron to run successfully, although a lot of these issues assume there's some reliability at reproducing this bug in Electron (it is not).
Maybe someone could give it and try and reproduce this in VM?
I've also tested this bug on the same hardware but different GPU drivers (Nouveau) and outside of some other errors to occur, I haven't encountered anything to be broken.
I can't isolate what cause thats issue but it's not wayland for sure.
all VM tests I did inherit the issue as long ascpu=host
is used (but for UBUNTU VM snapped webcord works, deb doesn't)
the same fedora build works on haswell based laptop, on zen3 doesn't
like I(it's not exactly me) wrote in electron bug you pointed out, build with chromium 116 is broken only. maybe some compile flags use wrong path for some CPUs but not for other. like https://github.com/SpacingBat3/WebCord/issues/452#issuecomment-1698000252
PS For first: many thanks for your support here with that issue I've started think we just should not bother, especially now, when you downgrade electron version with 4.4.1. we can only cross the finger for 27 would not break any platform
I've started think we just should not bother, especially now, when you downgrade electron version with 4.4.1.
@frosth555 I did not downgrade the Electron version, in fact I've upgraded Electron. I might try downgrading to v25 once I make sure no other regressions for different platforms are occuring – WebCord previously with v25 did crash on both Windows and macOS and the crash was reproducible enough that it happened for me on my both devices and I could additionaly reproduce it in WineHQ.
Not sure if this has been detailed, so I'll just throw it in anyway.
The 4.4.1 update made it to Flathub and on nvidia + gnome-shell 4.4.1 behaves slightly differently now - instead of just going grey after a few seconds, it now shows your friends list as before for a few seconds, but instead of just going grey and staying like that it repeatedly "logs in" and shows the Discord splash screen, then initial friends list again, then the Discord splash screen etc over and over.
Had to rollback to the 4.3.0 commit to fix it.
P.S. This is X11 not Wayland.
(...) but instead of just going grey and staying like that it repeatedly "logs in" and shows the Discord splash screen, then initial friends list again, then the Discord splash screen etc over and over.
This is expected to happen, WebCord now reloads the page in the approach to workaround the renderer crashes that don't constantly happen in the client. It should also restart itself with --safe-mode
in order to fix crashes caused by issues with GPU acceleration or some tweaks done by WebCord. If none of that helps, well… WebCord still tries to refresh the page.
The new update is slightly better. I can almost get to log in but once I scan the code or I am too slow, it just goes blank and restarts.
@RossComputerGuy
or I am too slow,
lol
Acknowledgements
[X] I have checked that there is no other issue describing the same or similar problem that I currently have, regardless if it has been closed or open.
[ ] This bug affects Discord website.
[ ] This issue is confirmed to be reproducible when WebCord is packaged on at least all three latest supported Electron major releases.
[ ] This issue is reproducible in Chrome, Chromium or any Chromium-based browser, e.g Brave or Edge (please write in Additional Context which browser you have used if it is neither Chrome nor unmodified Chromium).
[X] There are no fixes done to
master
which resolves this issue.[ ] My issue describes one of the unstable and/or not fully implemented features.
[X] I have found a workaround to mitigate or temporarily fix this issue in affected releases (please write it in Additional context section below).
Operating System / Platform
🐧️ Linux
Operating system architecture
x64 (64-bit Intel/AMD)
Electron version
26.0.0
Application version
v4.4.0
Bug description
After the last update (v4.4.0) all webcord windows turn blank / gray after a few seconds. This makes the application completely unusable. Reloading a window brings back its content, however it will turn blank after a couple of seconds again. This seems to happen under both Wayland and X11. The only workaround I have found is to downgrade back to v4.3.0. I have attached a video of this behavior.
https://github.com/SpacingBat3/WebCord/assets/70963316/2de49ef8-0b05-464a-9eb2-f25468d89031
Additional context
system information:
EDIT: This is an upstream issue of Electron 26. A workaround is to use Electron 25 instead of Electron 26 until the issue is resolved upstream.
MOD EDIT: The issue seems to be hardware-specific or setup-specific. However there are mixed reports for each driver (MESA AMDGPU,NVIDIA), which might mean this isn't somehow associated with the driver. I might verify if I can reproduce this on Wayland, as for me NVIDIA driver on X11 (XFCE4) works just fine.