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
[Bug]: Electron propagates GDK_BACKEND=x11 to subprocesses, breaking shell.openExternal with Firefox on Wayland #28436
Comments
electron/electron#28436 Signed-off-by: Anders Kaseorg <anders@zulip.com>
Looks like this was added by https://chromium-review.googlesource.com/c/chromium/src/+/2586184 cc @ckerr maybe you have thoughts? |
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 |
But couldn't that potentially cause problems for users who have explicitly set I think ideally Electron should only unset/revert the Full disclosure: I'm not familiar enough with Electron so maybe I'm totally off here in which case feel free to ignore this. |
Yup that is correct, I did mean removing the environment set by chromium in the parent process. |
Just ran into this with VSCodium 1.56. Is there a workaround until this is properly fixed? EDIT: Workaround: Add #!/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). |
@jplatte at least for Firefox itself there is this workaround: |
Actually I was getting crashes, not the "not responding" error message. But as noted above, I already put in another workaround. |
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
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)
Still broken in 21.0.1, 22.0.0-alpha.1, 23.0.0-nightly.20221004. Still waiting for #29606. |
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! |
Still an issue in 22.0.3, 23.0.0-beta.4, and 24.0.0-nightly.20230120. Still waiting for #29606. |
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! |
Hello, do you have any ETA for when it's going to be fixed? |
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! |
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! |
Stoppp it, bot. |
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
|
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 withMOZ_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 hasGDK_BACKEND=x11
in the environment. I confirmed that this is responsible for the failure with manual invocations ofI 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 asxdg-open
.The text was updated successfully, but these errors were encountered: