4.11.0 fails to start due to GTK symbols mixup

[bill88t]

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.

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

aarch64 (64-bit ARM)

Electron version

electron36-bin-36.2.1-1 for the webcord package, none was installed for the webcord-bin package

Application version

4.11.0

Bug description

The app fails to start with error: GTK 2/3 symbols detected. Using GTK 2/3 and GTK 4 in the same process is not supported

Additional context

Bug reportee's platform

Arch Linux ARM, the system is up to date.

Tested building webcord from the webcord package (which means, it was compiled on my machine) and the webcord-bin package, which uses binaries, neither worked.

Known workarounds

You may, for the time being, either add --gtk-version=3 flag to WebCord's command line or downgrade to Electron 35 or older.

Version 4.10.5 and below work fine.

[SpacingBat3]

Not sure about the origin of the bug, but it surely has to do something with the Electron version. Just downgrade to v35 for the time being. You might also try out official packages, maybe AppImages I distribute. As of x64, I couldn't repro the bug, at least on XFCE4. At worst it could have something to do with something outside the Electron, it would be great to run a debugger to find out exactly whenever Electron or some lib screwed it up.

[SpacingBat3]

See upstream bug report: https://github.com/electron/electron/issues/46538

~~Looks like the downgrade might be the only way and the bug might be architecture-agnostic. At least that's in case you use GNOME.~~

EDIT: You might also launch Electron software with --gtk-version=3 flag. It is also (likely) a Chrome/Chromium bug, so that's unlikely Electron devs will fix it, I'd expect that will be worked on by Chromium developers.

[bill88t]

Can confirm --gtk-version=3 makes the app function properly. Pasting --gtk-version=3 into ~/.config/webcord-flags.conf also makes the app function as intended.

Perhaps it would be meaningful to attempt to reproduce on x64 GNOME.

I don't have access to x64 hardware at the moment, but assuming it is reproduced there I think forcing GTK3 as a default flag, at least till it is fixed upsteam, would be the way to go.

#!/bin/bash

FLAGS_FILE="${XDG_CONFIG_HOME:-"${HOME}/.config"}/webcord-flags.conf"

[ -f "${FLAGS_FILE}" ] || exec '/opt/webcord/webcord' --gtk-version=3 "$@"

mapfile -t FLAGS_LINES < "${FLAGS_FILE}"
declare -a FLAGS

for line in "${FLAGS_LINES[@]}"; do
    [[ "${line}" =~ ^[[:space:]]*#.* ]] && continue
    FLAGS+=("${line}")
done

exec '/opt/webcord/webcord' "${FLAGS[@]}" "$@"

Is what I'd do for applying the flag by default, not forcing it for whoever has created a flags file.

[Enemico]

I can confirm this happens on debian12 as well.

[bill88t]

@Enemico Debian 12 x86_64 GNOME?

[SpacingBat3]

I don't have access to x64 hardware at the moment, but assuming it is reproduced there I think forcing GTK3 as a default flag, at least till it is fixed upsteam, would be the way to go.

Easier said than done, you could say: while adding some flags to Chromium before initialization is possible within Electron's application code, it might be futile for others and either be not respected at all, or be cause of weird respected, but not quite state and just make things even more awkward.

I recommend just applying the workaround individually, I don't think it is reproducible everywhere, even Electron dev team responses suggest that. So to conclude this, I don't plan working on it, it'll be fixed tho for the next release cycle.

[Enemico]

@Enemico Debian 12 x86_64 GNOME?

Yes. And the previous version did not show this problem. After install the app does not start at all, and the only way to get the message is trying to lanch it from a terminal. I also tried with different libgtk flavoured windows managers (standard gnome3, gnome-flashback) with always the (more or less) same result.

[bill88t]

If Debian and Arch GNOME are shat then that means basically any% GNOME is corked.

Conthegratulations, this issue will become a parade by tomorrow.

Easier said than done

Oh I though the launcher .sh was part of this repo, no it was part of the aur packages. I'll suggest it there instead.

But you should probably consider merging that in. It's what? 10 lines?

[SpacingBat3]

Oh I though the launcher .sh was part of this repo, no it was part of the aur packages. I'll suggest it there instead.

I don't. This launcher script is specifically made for Arch packages. Plus these flags are GNOME specific, not everything is GNOME in Linux world, just to consider. As to every workaround, they might be consequences to it. I'm not going to risk it.

I could apply some logic within the application code and try to apply flags there. I still don't like treating GNOME users differently from other Linux users. Plus, as said before, the results could be even worse. I don't daily drive GNOME, so either I would have to setup it for testing or send to someone who use it a testing build before pushing it further.

Conthegratulations, this issue will become a parade by tomorrow.

It's not the first Electron bug affecting some group of Linux users that can't be reproduced at all by others. I don't see why this scenario is different, I'd say I'd be glad this can even be workarounded without any downgrade.

[SpacingBat3]

Fun fact: this looks like is going to affect only GNOME. See this for more details: https://chromium-review.googlesource.com/c/chromium/src/+/6310469

[SpacingBat3]

OK, I've seen actually someone workarounding it via Electron API: might be worth giving it a try, but locking it for GNOME/Unix only platforms. I might publish the commit that workarounds it soon.

It still don't plan doing a full release, it's too soon for that. I'll wait for any other possible Electron conflicts to occur, plus do some code modernization before going with the next WebCord version.

[Enemico]

I am not sure about how you intend to fix the broken release. Will 4.11.0 contain the bugfix?

[HanabishiRecca]

Arch Linux electron36 package incorporated the workaround for everyone (available in 36.2.1-2). Although, it only affects native webcord package. But I could temporarily inject the flag into webcord-bin launch script by default too, as proposed above https://github.com/SpacingBat3/WebCord/issues/598#issuecomment-2888295742. P.S. Done in 4.11.0-2.

[inittux111]

If you launch it with --gtk-version=3 it will work, teams-for-linux has the same issue. https://github.com/IsmaelMartinez/teams-for-linux/issues/1731

[Cyriaque-TONNERRE]

Hi, same issue here on fedora 42, x86_64 Gnome, the flag --gtk-version=3 work well for me. ❤️

[SpacingBat3]

Should be resolved via Electron update, I believe this could be closed as fixed since WebCord v4.11.1.