Desktop snaps don't start at all in Xorg sessions if a Wayland session has been used
Metadata
Current evaluation
Desktop snaps fail to launch ("cannot open display") in Xorg sessions after a Wayland session was used, because desktop-exports detects Wayland by a leftover socket. Root cause identified; workaround DISABLE_WAYLAND=1; still open.
Suggested action: keep open
Reason: Maintainers triaged it (labels jammy/snap/x11; seb128 and ~vanvugt replied) and reproduced a deterministic sequence: 'Log into a Wayland session and launch Firefox. Log into a Xorg session and Firefox can't start.' The socket-based detection is still present at extensions/desktop/common/desktop-exports:257-275 (wayland_available set true if $XDG_RUNTIME_DIR/../wayland-0 is a socket, regardless of session type), so the bug is unfixed and affects all desktop snaps, not just firefox. Note the file header states this script is no longer used by the gnome extension for core22+, so the real fix now lives in canonical/snapcraft-desktop-integration, which lowers confidence that a change here alone resolves it.
Evaluated by: mr-cal-bot
Issue body
Evaluation history
| Date | Model | Scores | Action | Summary |
|---|---|---|---|---|
| stealth/space-bunny-alpha |
Impact:
55
Quick Win:
23
Complexity:
40
Confidence:
75
Actionability:
70
|
keep open | Desktop snaps fail to launch ("cannot open display") in Xorg sessions after a Wayland session was used, because desktop-exports detects Wayland by a leftover socket. Root cause identified; workaround DISABLE_WAYLAND=1; still open. | |
| stealth/space-bunny-alpha |
Impact:
52
Quick Win:
31
Complexity:
30
Confidence:
84
Actionability:
85
|
keep open | Desktop extension launcher scripts detect a Wayland session by probing for a lingering wayland socket, so snaps fail with 'cannot open display' in Xorg sessions after a prior Wayland session; reproducer and proposed $WAYLAND_DISPLAY check exist, still unfixed. | |
| stealth/space-bunny-alpha |
Impact:
68
Quick Win:
13
Complexity:
67
Confidence:
76
Actionability:
57
|
needs triage | Firefox snap fails in Xorg after prior Wayland use: $DISPLAY is :0, but launch reports “cannot open display: :0”; other X11 apps still work. No triage or activity. | |
| qwen3.6-35b-a3b-mtp-q6 |
Impact:
40
Quick Win:
28
Staleness:
95
Complexity:
30
Confidence:
60
Support Request:
60
|
close stale | Firefox snap fails to start in Xorg after Wayland session with 'cannot open display: :0' despite $DISPLAY being set. No maintainer response in 1632 days. | |
| qwen/qwen3.6-35b-a3b |
Staleness:
95
Complexity:
30
Confidence:
90
Support Request:
10
|
close stale | Firefox snap fails to launch in Xorg sessions after a Wayland session was used, showing display errors despite $DISPLAY being set. Issue remains unaddressed with no maintainer interaction. | |
| qwen/qwen3.6-35b-a3b |
Staleness:
95
Complexity:
40
Confidence:
85
Support Request:
10
|
close stale | Firefox snap fails to launch in Xorg after Wayland use, citing 'cannot open display: :0'. Issue is over four years old with no maintainer response. | |
| qwen3.6-35b-a3b-mtp-q6 |
Staleness:
95
Complexity:
30
Confidence:
85
Support Request:
20
|
close stale | Firefox snap fails to launch in Xorg sessions after a Wayland session, reporting display errors despite $DISPLAY being set. No maintainer response in over four years. |
Update history
| Date | Change |
|---|---|
| created |
Related work
-
Related To:
gnome-session#75
(confidence 55%)
Explicitly cited by ~osomon in the issue as part of the root cause: gnome-session leaves state so the next Xorg session looks like Wayland.
Related issues
No related issues found above the similarity threshold.