fix(desktop): strip Wayland env vars so launched apps stay on the lab display#16
Conversation
|
@codex review |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c7b9ae16b9
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| // Toolkits (GTK, Qt, Electron, Flutter) prefer Wayland when these are | ||
| // set, which would open the app on the user's real desktop instead of | ||
| // the isolated lab display. undefined values are dropped at spawn. | ||
| WAYLAND_DISPLAY: undefined, |
There was a problem hiding this comment.
WAYLAND_DISPLAY: undefined still leaves Wayland clients free to call wl_display_connect(NULL), which libwayland documents as falling back to wayland-0 under XDG_RUNTIME_DIR when WAYLAND_DISPLAY is unset (https://man.archlinux.org/man/extra/wayland-docs/wl_display.3.en#wl_display_connect). On a normal Wayland login using that default socket, GTK apps that try Wayland first can still open on the user's real compositor instead of the Xvfb DISPLAY; use a deliberately invalid Wayland display or force the X11 backend rather than deleting the variable.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Valid — fixed. WAYLAND_DISPLAY is now set to a deliberately invalid socket name (picklab-no-wayland) instead of being unset, forcing the X11 fallback even when the compositor listens on the default wayland-0.
|
@codex review |
|
Codex Review: Didn't find any major issues. Keep it up! Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
… display Toolkits (GTK, Qt, Electron, Flutter) prefer Wayland when WAYLAND_DISPLAY is set, so apps launched via desktop_launch opened on the user's real desktop instead of the isolated Xvfb display - and driving them moved the real cursor. Unset WAYLAND_DISPLAY and WAYLAND_SOCKET in the launch env so apps always render inside the lab display, which has its own pointer.
…nsetting it With the variable unset, wl_display_connect(NULL) falls back to the default wayland-0 socket, so Wayland-first toolkits could still reach the real compositor. An invalid socket name forces the X11 fallback.
ElbertePlinio
force-pushed
the
fix/lab-display-wayland-leak
branch
from
36f1580 to
bdc99a7
Compare
1 participant
What changed
desktop_launchoverrodeDISPLAYbut inheritedWAYLAND_DISPLAY/WAYLAND_SOCKETfrom the server process. Toolkits that prefer Wayland (GTK, Qt, Electron, Flutter) therefore opened "lab" apps on the user's real desktop instead of the isolated Xvfb display — and driving them there moved the real cursor.launchAppnow unsets both variables in the launched app's environment, so apps always render inside the lab display.docs/releases/UNRELEASED.mdupdated (user-facing change).Tested
DISPLAY=<lab display>and noWAYLAND_DISPLAY, even when the caller's env sets one.bun run typecheckclean.Not tested
Risks
Refs #15 (live-viewing follow-up: nested-display sessions).