SpacingBat3 / WebCord

A Discord and SpaceBar :electron:-based client implemented without Discord API.
MIT License
1.96k stars 98 forks source link

Webcord v4.4.0: Windows turning blank after couple of seconds #452

Closed JulianFP closed 1 year ago

JulianFP commented 1 year ago

Acknowledgements

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.

nicklozon commented 1 year 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.

JulianFP commented 1 year ago

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.

nicklozon commented 1 year ago

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.

JulianFP commented 1 year ago

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.

HanabishiRecca commented 1 year ago

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.

frosth555 commented 1 year ago

I can confirm that isse on arch (aur package), fedora (official rpm release) and unofficial flatpak. no matter wayland/xwayland/Xorg

HanabishiRecca commented 1 year ago

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.

SpacingBat3 commented 1 year ago

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?

SpacingBat3 commented 1 year ago

Also what about #444 and proposed workaround here? Maybe that's duplicate issue?

HanabishiRecca commented 1 year ago

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.

frosth555 commented 1 year ago

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

nicklozon commented 1 year ago

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

DylanElens commented 1 year ago

I also have this issue after updating yesterday. I am running on hyprland with intel igpu. On arch linux

OtaK commented 1 year ago

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!

r2rX commented 1 year ago

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).

nlunceford commented 1 year ago

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).

ravenclaw900 commented 1 year ago

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

r2rX commented 1 year ago

Then this issue doesn't seem to be related to #444 .

garyoakidoki commented 1 year ago

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/

0xGingi commented 1 year ago

Oddly, the grey screen issue on AMD/Mesa is nonexistent on Electron 27 Alpha, but persists on 26

frosth555 commented 1 year ago

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

soumyaDghosh commented 1 year ago

This issue doesn't bother the snap though. It works fine.

carabistouflette commented 1 year ago

i have this issue too as an arch user

SpacingBat3 commented 1 year ago

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).

soumyaDghosh commented 1 year ago

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.

frosth555 commented 1 year ago

https://github.com/electron/electron/issues/39515 Looks pretty close

SpacingBat3 commented 1 year ago

What's about Electron 26.1.0? Can anyone check it out?

frosth555 commented 1 year ago

On electron 26.1.0 issue still persist

SpacingBat3 commented 1 year ago

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?

frosth555 commented 1 year ago

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
EricDriussi commented 1 year ago

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...

AdivonSlav commented 1 year ago

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

pezz commented 1 year ago

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.

EricDriussi commented 1 year ago

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.

demirdegerli commented 1 year ago

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
SpacingBat3 commented 1 year ago

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.

SpacingBat3 commented 1 year ago

Also see: https://github.com/SpacingBat3/WebCord/issues/444#issuecomment-1704388025.

scottAnselmo commented 1 year ago

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

SpacingBat3 commented 1 year ago

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?

SpacingBat3 commented 1 year ago

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.

whao commented 1 year ago

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
    }
  ]
}
RossComputerGuy commented 1 year ago

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.

aarnaud commented 1 year ago

I had to rollback to 4.3 too

SpacingBat3 commented 1 year ago

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.

frosth555 commented 1 year ago

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

SpacingBat3 commented 1 year ago

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.

pezz commented 1 year ago

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.

SpacingBat3 commented 1 year ago

(...) 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.

RossComputerGuy commented 1 year ago

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.

demirdegerli commented 1 year ago

@RossComputerGuy

or I am too slow,

lol