Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug]: Electron propagates GDK_BACKEND=x11 to subprocesses, breaking shell.openExternal with Firefox on Wayland #28436

Open
3 tasks done
andersk opened this issue Mar 30, 2021 · 19 comments · Fixed by #28898 · May be fixed by bavulapati/electron#1 or #32929
Open
3 tasks done

Comments

@andersk
Copy link
Contributor

andersk commented Mar 30, 2021

Preflight Checklist

Electron Version

12.0.9
13.0.1
14.1.0
15.1.1

What operating system are you using?

Other Linux

Operating System Version

NixOS 21.05

What arch are you using?

x64

Last Known Working Electron version

12.0.0-beta.20

Expected Behavior

shell.openExternal("https://electronjs.org/") opens a browser tab at https://electronjs.org/. (My browser is Firefox on Wayland with MOZ_ENABLE_WAYLAND=1, and has other tabs already open.)

Actual Behavior

Firefox shows this error and does not open a tab:

“Firefox is already running, but is not responding. To use Firefox, you must first close the existing Firefox process, restart your device, or use a different profile.”

Testcase Gist URL

https://gist.github.com/31ec2165f4aa806536e11d7d99d1e26f

I bisected this to v12.0.0-beta.20...v12.0.0-beta.21 (9faf235...5dbb635).

The difference between v12.0.0-beta.20’s working invocation of xdg-open and v12.0.0-beta.21’s failing invocation is that the latter has GDK_BACKEND=x11 in the environment. I confirmed that this is responsible for the failure with manual invocations of

xdg-open https://electronjs.org/  # works
env GDK_BACKEND=x11 xdg-open https://electronjs.org/  # fails

I don’t know if Electron or Chromium need to set GDK_BACKEND=x11 for their own purposes, but it definitely should not be propagated to subprocesses such as xdg-open.

andersk added a commit to zulip/zulip-desktop that referenced this issue Mar 30, 2021
@codebytere
Copy link
Member

codebytere commented Mar 30, 2021

Looks like this was added by https://chromium-review.googlesource.com/c/chromium/src/+/2586184

cc @ckerr maybe you have thoughts?

@deepak1556
Copy link
Member

Since we inherit the parent process environment for the process launch operation https://github.com/electron/electron/blob/master/shell/common/platform_util_linux.cc#L116 , we should remove GDK_BACKEND from the launch options environment, that can affect external app behaviors.

@vially
Copy link
Contributor

vially commented Apr 26, 2021

we should remove GDK_BACKEND from the launch options environment

But couldn't that potentially cause problems for users who have explicitly set GDK_BACKEND in their environment, but which was then overwritten by Chromium as mentioned above?

I think ideally Electron should only unset/revert theGDK_BACKEND set by chromium while still keeping the user's original GDK_BACKEND (if set). Maybe something similar to this code block regarding LC_ALL in electron_browser_main_parts.cc.

Full disclosure: I'm not familiar enough with Electron so maybe I'm totally off here in which case feel free to ignore this.

@deepak1556
Copy link
Member

Yup that is correct, I did mean removing the environment set by chromium in the parent process.

@jplatte
Copy link

jplatte commented May 11, 2021

Just ran into this with VSCodium 1.56. Is there a workaround until this is properly fixed?

EDIT: Workaround: Add /usr/local/bin/xdg-open (assuming /usr/local/bin is in your PATH) with

#!/bin/sh
unset GDK_BACKEND
/usr/bin/xdg-open $@

and make it executable (this is assuming you don't sometimes need that value, of course).

@fabiscafe
Copy link

@jplatte at least for Firefox itself there is this workaround:
https://wiki.archlinux.org/title/Firefox#Applications_on_Wayland_can_not_launch_Firefox

@jplatte
Copy link

jplatte commented May 11, 2021

Actually I was getting crashes, not the "not responding" error message. But as noted above, I already put in another workaround.

Ma27 added a commit to Ma27/nixpkgs that referenced this issue Jun 4, 2021
ChangeLog: https://github.com/getferdi/ferdi/blob/1886c8abed32e33f0f547c069c674b79279cf931/CHANGELOG.md#560-beta6-2021-05-31

Even though this isn't explicitly noted in the Changelog, this seems to
have fixed the Element integration for me.

Additionally, I added a (hacky) `xdg-open` wrapper which removes the
`GDK_BACKEND` variable to fix the XWayland integration[1]. The problem
is that if a Firefox is running with Wayland (`ferdi` is running under
X11) and `GDK_BACKEND=x11` is passed to the `xdg-open` (and thus
`firefox`) process, Firefox refuses to start since another instance of
it is running under Wayland (but attempts to start in X11 mode because of
`GDK_BACKEND=x11`).

[1] electron/electron#28436
github-actions bot pushed a commit to NixOS/nixpkgs that referenced this issue Jun 5, 2021
ChangeLog: https://github.com/getferdi/ferdi/blob/1886c8abed32e33f0f547c069c674b79279cf931/CHANGELOG.md#560-beta6-2021-05-31

Even though this isn't explicitly noted in the Changelog, this seems to
have fixed the Element integration for me.

Additionally, I added a (hacky) `xdg-open` wrapper which removes the
`GDK_BACKEND` variable to fix the XWayland integration[1]. The problem
is that if a Firefox is running with Wayland (`ferdi` is running under
X11) and `GDK_BACKEND=x11` is passed to the `xdg-open` (and thus
`firefox`) process, Firefox refuses to start since another instance of
it is running under Wayland (but attempts to start in X11 mode because of
`GDK_BACKEND=x11`).

[1] electron/electron#28436

(cherry picked from commit cd4ad7d)
@andersk
Copy link
Contributor Author

andersk commented Oct 7, 2021

The fix in #28898 was reverted in #29610, and has not yet been reapplied in #29606. This still reproduces in 14.1.0 and 15.1.1. Please reopen.

@andersk
Copy link
Contributor Author

andersk commented Oct 5, 2022

Still broken in 21.0.1, 22.0.0-alpha.1, 23.0.0-nightly.20221004. Still waiting for #29606.

@github-actions
Copy link
Contributor

This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. If you have any new additional information—in particular, if this is still reproducible in the latest version of Electron or in the beta—please include it with your comment!

@andersk
Copy link
Contributor Author

andersk commented Jan 21, 2023

Still an issue in 22.0.3, 23.0.0-beta.4, and 24.0.0-nightly.20230120. Still waiting for #29606.

@github-actions
Copy link
Contributor

This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. If you have any new additional information—in particular, if this is still reproducible in the latest version of Electron or in the beta—please include it with your comment!

@github-actions github-actions bot added the stale label Apr 22, 2023
@andersk
Copy link
Contributor Author

andersk commented Apr 22, 2023

Still broken in 24.1.2, 25.0.0-alpha.4, and 26.0.0-nightly.20230421. Still waiting for #29606/#32929.

@JoanVicens
Copy link

Hello, do you have any ETA for when it's going to be fixed?

@electron-issue-triage
Copy link

This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. If you have any new additional information—in particular, if this is still reproducible in the latest version of Electron or in the beta—please include it with your comment!

@andersk
Copy link
Contributor Author

andersk commented Oct 10, 2023

Still an issue in 26.3.0, 27.0.0-beta.9, and 28.0.0-nightly.20231009. Still wilting for #29606/#32929.

@electron-issue-triage
Copy link

This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. If you have any new additional information—in particular, if this is still reproducible in the latest version of Electron or in the beta—please include it with your comment!

@andersk
Copy link
Contributor Author

andersk commented Jan 9, 2024

Stoppp it, bot.

@tim-rex
Copy link

tim-rex commented Mar 13, 2024

Discovered this to be an issue here

What's interesting is that I'm explicitly running VScode as a native Wayland application but still seeing GDK_BACKEND=x11 regardless

$ cat .config/electron27-flags.conf 
--enable-features=WaylandWindowDecorations
--ozone-platform-hint=auto

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment