Version 4.4.2 won't start.

[ghost]

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.

• [X] 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.

• [ ] 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

Idk

Application version

4.4.2

Bug description

Installed it through the .deb package today, and it just does nothing.

Additional context

No response

[SpacingBat3]

Electron Forge went crazy last night for me, I'll check the debs but I highly doubt there will be any regression there. At least definitely not on my side. Given I don't use Debian-based DE daily, I'll probably just extract the binary from it and run.

Also, what about webcord in the console (/bin/)? Got any logs with that?

[NekognitoTab]

I've encountered the same issue after installing the v4.4.2 amd64 .deb-file. For the logs, I've tried webcord, webcord --verbose and webcord --safe-mode --verbose. But none of them showed any logs in the console, while also indefinitely running.

For all the commands I've tried, according to btop, the first webcord process thread took 100% of one of my cores. And after 10 minutes, the RAM also rose up to 2.5G for the aforementioned process.

[patchedsoul]

MacOS builds are also broken

[bash-ful]

I also experienced the same issue as NekognitoTab on the official AUR, where running webcord --safe-mode opens an instance of webcord with a blank gray screen. No logs or anything on the terminal. I tried it both on arch's latest electron which should be 25 and electron24.

Cloning this repo and running via npm run start runs webcord for me. There is a weird quirk/issue when opening the About option on the Menu bar though, where the terminal throws [WC_9:133] crashed errors, where webcord inevitably relaunches in safe mode shortly afterwards.

[thespad]

Similarly, deb won't start but building from source and running through npm run start is working.

[JulianHeuser]

Same issue here as well with the deb on mint

[Cherro59]

Same on 4.4.2 fedora 38. Both rpm and AppImage

[SpacingBat3]

I've been testing this for a while, it looks like that for some reason Electron doesn't like running WebCord once it is packaged to asar, I've noticed some issues (in attached DevTools console to main process, with --inspect and development builds) with ESM resolver trying to load a dependency in wrong path. Sounds like an Electron/asar side bug?

[SpacingBat3]

OK, I found the upstream issue ticket: https://github.com/electron/electron/issues/38829.

As referenced in upstream issue, import() (and most likely the whole ESM resolver) doesn't work in app.asar yet, at least with the partial ESM support Electron introduced in versions <28. There's a chance however with the full ESM support in Electron, this bug will be fixed and it will be possible to use import within app.asar.

So, there are currently two ways to resolve this issue right now:

1. Revert Node16 commit and go back to relying on require() (just as in WebCord 4.1.1).
2. Not packaging WebCord into app.asar (preferably only for modules/files loaded in ESM context), which may make the performance worse in some cases (Electron suggested app.asar may help Windows with loading multiple files; on the other hand WebCord's app.asar is unordered and this could already lower the performance depending on byte offsets of specific files in app.asar archive).

I guess I could go with 1. and just revert the commit that enables Node16, then re-enable it once Electron 28 will be published as a stable release and will support ESM module resolution correctly inside app.asar.

[patchedsoul]

Tested 4.4.3, MacOS still appears to be broken

[SpacingBat3]

Fixed in https://github.com/SpacingBat3/WebCord/commit/6773fec75361dc6cce719facd29ae31e073fc180 and WebCord v4.4.3 :tada:.

[SpacingBat3]

Tested 4.4.3, MacOS still appears to be broken

@patchedsoul I suppose you mean the bug with the renderer process constantly crashing, like with v4.4.1? Because with v4.4.3 the window pops out correctly (it didn't previously with v4.4.2).