Issue with Electron 18.0.0-18.2.3 on older Linux distributions.

[theofficialgman]

Aknowledgements

• I have checked that there's no other issue describing the same or
  similar problem that I currently have, regardless if it has been
  closed or open.

• I can confirm that this is not an issue with the Discord website,
  but it is a problem specific to the WebCord itself.

• I have tried running the build from the master branch and it does
  not have any fixes implemented according to my 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
  (please write it in Additional context section).

Operating System / Platform

🐧️ Linux

Operating system architecture

aarch64 (64-bit ARM)

Electron version

18.X

Application version

3.1.4

Bug description

upstream electron bug affecting usage on bionic/buster and older linux distros (all architectures). this has been fixed in 19.X prereleases and does not exist in 17.X or earlier. the bug causes the application to error on launch due to unavailable dependencies

electron/electron#33533

Additional context

No response

[SpacingBat3]

I have found a workaround to mitigate or temporarily fix this issue
(please write it in Additional context section).

And what is that? A downgrade is not a workaround, neither rebuilding the app. A workaround would be a way to bypass the limitations of the issue with the existing binaries.

---

I guess I could provide tarballs there for 3.1.4 releases packaged with the Electron 17.x.y for Linux AArch64 (or actually publish them like I did with other distributables within the releases) until the problem will be fixed on the Electron's side.

[SpacingBat3]

@theofficialgman I've uploaded webcord-3.1.4-linux-aarch64-electron17.tar.xz in the releases for those who has any troubles with Electron 18. For now I won't downgrade the Electron version for everybody, but the one can still build it on their own (as of the development releases) under the older Electron releases as well.

[SpacingBat3]

Also since this is kinda resolved for now, I'll close this issue, but it will be still open for the discussion if anything still seems to be broken.

[theofficialgman]

I think you failed to recognize this is not an aarch64 issue with electron 18. its an issue across all architectures that affects many distros which normally are supported by electron (ubuntu bionic, ubuntu focal, debian buster, etc)

@Itai-Nelken I'm going to suggest that you NOT update your apt repo with webcord until either this is fixed upstream, or @SpacingBat3 decides to revert to 17 (no reason not to, just use a later 17.X release with the bugfixes and CVEs fixed, eg 17.4.3)

[SpacingBat3]

Actually I've found that earlier. However I'm thinking why no one just could provide this lib specifically for the Electron? One of the reasons is that I found some users (mostly Arch ones) needs to use the 18.x.y builds. The other thing is that I made my application to follow all of the recommended Electron security practises, including using the latest Electron version available. This is why I keep finding a workarounds for Electron issues over being stuck with the outdated Electron releases – if that would be the case, I believe WebCord would be stuck with the Electron 13 or at least 15, because release 16 introduced a bug with the applications' storage (this is were your login data and settings are saved), which I have found a workaround for.

[theofficialgman]

However I'm thinking why no one just could provide this lib specifically for the Electron? One of the reasons is that I found some users (mostly Arch ones) needs to use the 18.x.y builds.

electron has a multi stable release model. 18.x.y, 17.x.y, 16.x.y, 15.x.y are all maintained with the latest security patches that link you posted is probably out of date and does not represent the current electron release model.

the current bug is simply an error with the declaration of a function, there is 0 reason that electron should be linking to `

/libxkbcommon.so.0: version `V_1.0.0'

that version is NOT available on bionic/buster/focal and electron states they build on a bionic install. you can see here it was SUPPOSED to be a weak declaration and check at runtime and be non-fatal, but this turned out not to be the case https://chromium-review.googlesource.com/c/chromium/src/+/3422444/6/ui/events/ozone/layout/xkb/xkb_keyboard_layout_engine.cc
as you can tell, this didn't work as intended and debian maintainers had to fix the declaration to be compatible on buster/bionic

https://bazaar.launchpad.net/~chromium-team/chromium-browser/bionic-beta/revision/1624/debian/patches/ozone-no-xkb_keymap_key_get_mods_for_level.patch

so its your choice how you proceed, either you downgrade to an actually stable and secure release like 17.x.y or wait around for electron to catch up on a fix thats been available to them for months, or use the electron 19 prereleases where the chromium change was reverted and hence there is no problem

[theofficialgman]

the fix was just pulled into 18.x.y electron branch today. it did not make it into v18.2.3, but will be in v18.2.4
electron/electron#34155

[theofficialgman]

@SpacingBat3 electron 18.2.4 has been released, time to rebuild
I suggest changing to "electron": "^18.2.4", so that nobody builds on a broken release as well

[SpacingBat3]

@SpacingBat3 electron 18.2.4 has been released, time to rebuild I suggest changing to "electron": "^18.2.4", so that nobody builds on a broken release as well

No, it doesn't need to be bumped, as described in NPM's semver documentation. I only need to re-run the jobs so it will re-generate the distributables...

[arrowgent]

ubuntu 18.04 x86_64

just updated 3.1.4, file build date suggests may 18th 2022 (electron 18.2.4 included)

no issues

[theofficialgman]

all good, thanks for re-running it